From Alan.Hayward at arm.com  Thu Jul  1 09:30:25 2021
From: Alan.Hayward at arm.com (Alan Hayward)
Date: Thu, 1 Jul 2021 09:30:25 +0000
Subject: [8u] RFR 8266749: AArch64: Backtracing broken on PAC enabled
 systems
In-Reply-To: <8F7FC887-2EDE-4086-B40E-AC74B61E5FA4@amazon.com>
References: <8F7FC887-2EDE-4086-B40E-AC74B61E5FA4@amazon.com>
Message-ID: <58FDA965-DA86-4C30-8375-A1D977E44203@arm.com>

Thanks.

I?ve now added the fix request to the bug (https://bugs.openjdk.java.net/browse/JDK-8266749)
I should have done that before.

Requesting approval and then sponser please.



Alan.

On 30 Jun 2021, at 17:37, Hohensee, Paul <hohensee at amazon.com<mailto:hohensee at amazon.com>> wrote:

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net<mailto:jdk8u-dev-retn at openjdk.java.net>> on behalf of Alan Hayward <Alan.Hayward at arm.com<mailto:Alan.Hayward at arm.com>>
Date: Tuesday, June 29, 2021 at 2:34 AM
To: "jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>" <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>
Subject: [8u] RFR 8266749: AArch64: Backtracing broken on PAC enabled systems

Hi,
I?d like to backport this fix.

Webrev: http://cr.openjdk.java.net/~ahayward/8266749/webrev/

On fedora 33 (and onwards), openJDK is build with PAC enabled on Aarch64.
This patch is required to make the backtracking work.

Tested manually on Fedora 33 on a PAC system (VM on M1 Mac)

Applied cleanly from TIP version, except for
* Files moved into VM directories
* New Windows and Mac files removed from patch.

I also have an 11u version awaiting review here: https://github.com/openjdk/jdk11u-dev/pull/39


(First time using webrev and back porting, so apologies if I?ve missed something)


Thanks,
Alan.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.



From Alan.Hayward at arm.com  Thu Jul  1 10:44:09 2021
From: Alan.Hayward at arm.com (Alan Hayward)
Date: Thu, 1 Jul 2021 10:44:09 +0000
Subject: [8u] RFR 8266749: AArch64: Backtracing broken on PAC enabled
 systems
In-Reply-To: <8F7FC887-2EDE-4086-B40E-AC74B61E5FA4@amazon.com>
References: <8F7FC887-2EDE-4086-B40E-AC74B61E5FA4@amazon.com>
Message-ID: <412C11C7-748A-4594-90C9-D7F1F37FE81D@arm.com>

Thanks.

I?ve now added the fix request to the bug (https://bugs.openjdk.java.net/browse/JDK-8266749)
I should have done that before.

Requesting approval and then sponser please.



Alan.

On 30 Jun 2021, at 17:37, Hohensee, Paul <hohensee at amazon.com<mailto:hohensee at amazon.com>> wrote:

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net<mailto:jdk8u-dev-retn at openjdk.java.net>> on behalf of Alan Hayward <Alan.Hayward at arm.com<mailto:Alan.Hayward at arm.com>>
Date: Tuesday, June 29, 2021 at 2:34 AM
To: "jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>" <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>
Subject: [8u] RFR 8266749: AArch64: Backtracing broken on PAC enabled systems

Hi,
I?d like to backport this fix.

Webrev: http://cr.openjdk.java.net/~ahayward/8266749/webrev/

On fedora 33 (and onwards), openJDK is build with PAC enabled on Aarch64.
This patch is required to make the backtracking work.

Tested manually on Fedora 33 on a PAC system (VM on M1 Mac)

Applied cleanly from TIP version, except for
* Files moved into VM directories
* New Windows and Mac files removed from patch.

I also have an 11u version awaiting review here: https://github.com/openjdk/jdk11u-dev/pull/39


(First time using webrev and back porting, so apologies if I?ve missed something)


Thanks,
Alan.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.



From m.yamamoto at change-vision.com  Fri Jul  2 04:14:31 2021
From: m.yamamoto at change-vision.com (Mitsuhiro Yamamoto)
Date: Fri, 2 Jul 2021 13:14:31 +0900
Subject: JOptionPane-Icons only partially visible when using Windows 10 L&F
Message-ID: <CAKcZAWxmj2ZV6WpvRAj=kL2q2ji659KQ+kFiX6vLKh-+K3DOmg@mail.gmail.com>

Hi there,

Could you please apply the following bugs to Java 8 as well?

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8151385

Best Regards,
Mit

From m.yamamoto at change-vision.com  Fri Jul  2 04:25:56 2021
From: m.yamamoto at change-vision.com (Mitsuhiro Yamamoto)
Date: Fri, 2 Jul 2021 13:25:56 +0900
Subject: JTabbedPane selected tab text is barely legible
Message-ID: <CAKcZAWzPBZi12Y8Y-DzJRDzp2ZsgNCQ13v9ndMN5Ys00fi4ojg@mail.gmail.com>

Hi there,

Could you please apply the following bugs to Java 8 as well?

https://bugs.openjdk.java.net/browse/JDK-8253702

Best Regards,
Mit

From sgehwolf at redhat.com  Fri Jul  2 13:07:09 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 02 Jul 2021 15:07:09 +0200
Subject: [8u] RFR: 8269810: [8u] Update generated_configure.sh after
 JDK-8250876 backport
Message-ID: <494095e11ecca871b3cf5561eea351e153bd78d4.camel@redhat.com>

Hi!

Latest jdk8u/jdk8u-dev head is out of sync as far as
generated_configure.sh is concerned. JDK-8250876 didn't include the
generated_configure.sh update. This patch fixes it (it's the output of
'bash common/autoconf/autogen.sh')

Bug: https://bugs.openjdk.java.net/browse/JDK-8269810
webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8269810/01/webrev/

Thoughts?

Thanks,
Severin


From sgehwolf at redhat.com  Fri Jul  2 15:19:54 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 02 Jul 2021 17:19:54 +0200
Subject: [8u] RFR (S) 8065215: Print warning summary at end of configure
In-Reply-To: <43a6cc4b-a735-8d1f-45d2-714c9ed64145@redhat.com>
References: <43a6cc4b-a735-8d1f-45d2-714c9ed64145@redhat.com>
Message-ID: <f0bd53cf29ef707922265d707ad2c2448e09940b.camel@redhat.com>

On Tue, 2021-04-27 at 11:52 +0200, Aleksey Shipilev wrote:
> Original RFE:
> ?? https://bugs.openjdk.java.net/browse/JDK-8065215
> ?? https://hg.openjdk.java.net/jdk9/jdk9/rev/eefa97d0d263
> 
> I would like to backport this 8u build system change to improve error detection during configure. 
> This also allows cleaner backport of JDK-8079891.
> 
> The patch has a few minor differences:
> ?? *) There is no CUSTOM_SUMMARY_AND_WARNINGS_HOOK, no configure.ac hunk does not apply automatically;
> ?? *) There are no relevant "has been successfully created" blocks in help.m4;
> ?? *) generated-configure.sh is obviously different;
> 
> 8u webrev:
> ?? https://cr.openjdk.java.net/~shade/8065215/webrev.8u.01/

This looks OK to me. Note that generated_configure.sh needs to get re-
generated. Currently the 8u-dev tree is out of sync (see JDK-8269810).

Thanks,
Severin


From sgehwolf at redhat.com  Fri Jul  2 15:21:49 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 02 Jul 2021 17:21:49 +0200
Subject: [8u] RFR (S) 8079891: Store configure log in $BUILD/configure.log
In-Reply-To: <b3a2c022-97c7-1d6d-64ec-e79c8132194e@redhat.com>
References: <b3a2c022-97c7-1d6d-64ec-e79c8132194e@redhat.com>
Message-ID: <354dc4caea576aff2d97e8d1dceedb9156e9197c.camel@redhat.com>

On Tue, 2021-04-27 at 12:01 +0200, Aleksey Shipilev wrote:
> Original RFE:
> ?? https://bugs.openjdk.java.net/browse/JDK-8079891
> ?? https://hg.openjdk.java.net/jdk9/jdk9/rev/98e85b507b09
> 
> I would like to have this simple build feature in 8u to better report configuration logs from 8u 
> CIs. This patch applies mostly trivially, with the following changes:
> ?? *) Blocks mentioning CONFIGURESUPPORT_OUTPUTDIR are removed, as these are not relevant to 8u 
> build system;
> ?? *) Minor contextual conflicts are resolved;
> 
> Current patch needs JDK-8065215 applied first to get the help block at the end of configure. This 
> also needs JDK-8080082 as the follow-up.
> 
> Testing: 8u build; observing configure.log in build artifacts

Missing a link to the webrev?

Thanks,
Severin


From sgehwolf at redhat.com  Fri Jul  2 15:29:53 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 02 Jul 2021 17:29:53 +0200
Subject: [8u] RFR (XS) 8080082: configure fails if you create an empty
 directory and then run configure from it
In-Reply-To: <c76a0a8e-3638-7163-cfbe-70992f8d2500@redhat.com>
References: <c76a0a8e-3638-7163-cfbe-70992f8d2500@redhat.com>
Message-ID: <9d7d10f873b82fb6f2dc714f911f5fa5569e7762.camel@redhat.com>

On Tue, 2021-04-27 at 12:09 +0200, Aleksey Shipilev wrote:
> 8u webrev:
> ?? https://cr.openjdk.java.net/~shade/8080082/webrev.8u.01/

LGTM. Please generate configure from scratch before you push.

Thanks,
Severin


From mails.mail.openjdk.java.net at gunter.ohrner.net  Sun Jul  4 14:48:01 2021
From: mails.mail.openjdk.java.net at gunter.ohrner.net (Gunter Ohrner)
Date: Sun, 4 Jul 2021 16:48:01 +0200
Subject: =?UTF-8?Q?OpenJDK_8_292_=28and_212=29_SIGSEGV_inInstanceKlass=3A=3Am?=
 =?UTF-8?Q?ethod=5Fwith=5Forig=5Fidnum?=
Message-ID: <e55a5a51-e638-737f-8b9a-50dc87b6ae83@ohrner.net>

Hi everyone,


I hope I'm on the correct list here - I can't seem to get direct access 
to the OpenJDK bug tracker and was pointed here to report a crash.

It's consistently reproducable on one Debian 10 "Buster" x64 machine 
with as well AdoptOpenJDK-build 1.8.0 292? and Amazon Corretto builds 
1.8.0 292 and 212 (always with the same stack trace).

The hs_err logfile is attached.

The crash is independend of the Garbage Collector (also tried with G1), 
and also identically occurs in interpreted mode (-Xint).

Where it gets strange is that I could run the tests successfully for a 
while in a Buster and a Bullseye chroot on the same machine (managed 
using the schroot tool), but now it also fails in these chroots 
identically. The chroots include their separate copies of the code and a 
separate JVM installation, of course.

I'd be happy to provide additional information, but I'm running out of 
ideas right now...

Unfortunately, I cannot provide the code which causes the crash. :-(


Stack: [0x00007f630f93d000,0x00007f630fa3e000], sp=0x00007f630fa38b00,? 
free space=1006k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
C=native code)
V? [libjvm.so+0x64e5e2] InstanceKlass::method_with_orig_idnum(int, int)+0x42
V? [libjvm.so+0x69ca48] java_lang_StackTraceElement::create(Handle, int, 
int, int, int, Thread*)+0x158
V? [libjvm.so+0x69cf25] 
java_lang_Throwable::get_stack_trace_element(oopDesc*, int, Thread*)+0x265
V? [libjvm.so+0x732ece]? JVM_GetStackTraceElement+0x6e
J 3146 
java.lang.Throwable.getStackTraceElement(I)Ljava/lang/StackTraceElement; 
(0 bytes) @ 0x00007f6355df56e8 [0x00007f6355df5640+0xa8]
J 13697 C1 
java.lang.Throwable.getOurStackTrace()[Ljava/lang/StackTraceElement; (80 
bytes) @ 0x00007f63567476f4 [0x00007f63567472c0+0x434]
J 13696 C1 
java.lang.Throwable.printStackTrace(Ljava/lang/Throwable$PrintStreamOrWriter;)V 
(177 bytes) @ 0x00007f635674d244 [0x00007f635674cb60+0x6e4]
j? java.lang.Throwable.printStackTrace(Ljava/io/PrintStream;)V+9
j? org.eclipse.emf.common.EMFPlugin.log(Ljava/lang/Object;)V+23
j 
org_w3_xml_1998_namespace.Org_w3_xml_1998_namespaceFactory.init()Lorg_w3_xml_1998_namespace/Org_w3_xml_1998_namespaceFactory;+28
j org_w3_xml_1998_namespace.Org_w3_xml_1998_namespaceFactory.<clinit>()V+0
v? ~StubRoutines::call_stub
V? [libjvm.so+0x694eaa]? JavaCalls::call_helper(JavaValue*, 
methodHandle*, JavaCallArguments*, Thread*)+0xe1a
V? [libjvm.so+0x64f1bf] 
InstanceKlass::call_class_initializer_impl(instanceKlassHandle, 
Thread*)+0x10f
V? [libjvm.so+0x64f6b7] 
InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x387
V? [libjvm.so+0x64f901]? InstanceKlass::initialize(Thread*)+0x51
V? [libjvm.so+0x814da9] LinkResolver::resolve_field(fieldDescriptor&, 
KlassHandle, Symbol*, Symbol*, KlassHandle, Bytecodes::Code, bool, bool, 
Thread*)+0x259
V? [libjvm.so+0x815369] 
LinkResolver::resolve_field_access(fieldDescriptor&, constantPoolHandle, 
int, Bytecodes::Code, Thread*)+0x179
(...)


Best regards,

 ? Gunter

-- 

Ohrner IT GmbH                  Tel.: 07031 / 202929-0
Otto-Lilienthal-Str. 36         Fax:  07031 / 202929-99
71034 B?blingen                 Mail: go at ohrner-it.com

Registergericht:                Stuttgart, HRB 755190
Gesch?ftsf?hrer:                Gunter Ohrner
St-Nr.: 56463/00876             Ust-Id Nr.: DE253014984


From shade at redhat.com  Mon Jul  5 07:22:30 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 5 Jul 2021 09:22:30 +0200
Subject: OpenJDK 8 292 (and 212) SIGSEGV
 inInstanceKlass::method_with_orig_idnum
In-Reply-To: <e55a5a51-e638-737f-8b9a-50dc87b6ae83@ohrner.net>
References: <e55a5a51-e638-737f-8b9a-50dc87b6ae83@ohrner.net>
Message-ID: <e2a83cfd-9907-4350-0577-4fadb660bae2@redhat.com>

Hi,

On 7/4/21 4:48 PM, Gunter Ohrner wrote:
> It's consistently reproducable on one Debian 10 "Buster" x64 machine
> with as well AdoptOpenJDK-build 1.8.0 292? and Amazon Corretto builds
> 1.8.0 292 and 212 (always with the same stack trace).

Could you please run with fastdebug build and say if it fails with the assert? You can try a 
fastdebug build from here:
   https://builds.shipilev.net/openjdk-jdk8-dev/

 From the bug tracker, I think this is a suspect:
   https://bugs.openjdk.java.net/browse/JDK-8194246

> The hs_err logfile is attached.

This mailing list strips the attachments, unfortunately. Please post the asserts message and the 
stack trace inline next time.

-- 
Thanks,
-Aleksey


From mails.mail.openjdk.java.net at gunter.ohrner.net  Mon Jul  5 07:29:59 2021
From: mails.mail.openjdk.java.net at gunter.ohrner.net (Gunter Ohrner)
Date: Mon, 5 Jul 2021 09:29:59 +0200
Subject: =?UTF-8?Q?Re=3A_OpenJDK_8_292_=28and_212=29SIGSEGVinInstanceKlass=3A=3A?=
 =?UTF-8?Q?method=5Fwith=5Forig=5Fidnum?=
In-Reply-To: <e2a83cfd-9907-4350-0577-4fadb660bae2@redhat.com>
References: <e55a5a51-e638-737f-8b9a-50dc87b6ae83@ohrner.net>
 <e2a83cfd-9907-4350-0577-4fadb660bae2@redhat.com>
Message-ID: <3c7b1bab-870d-aa90-aa63-00063927b9e7@ohrner.net>

Am 05.07.21 um 09:22 schrieb Aleksey Shipilev:
> On 7/4/21 4:48 PM, Gunter Ohrner wrote:
>> It's consistently reproducable on one Debian 10 "Buster" x64 machine
>> with as well AdoptOpenJDK-build 1.8.0 292? and Amazon Corretto builds
>> 1.8.0 292 and 212 (always with the same stack trace).
>
> Could you please run with fastdebug build and say if it fails with the 
> assert? You can try a fastdebug build from here:
> ? https://builds.shipilev.net/openjdk-jdk8-dev/

Ok, will try.


>> The hs_err logfile is attached.
>
> This mailing list strips the attachments, unfortunately. Please post 
> the asserts message and the stack trace inline next time.

I did when I noticed it was missing, but the resulting mail was so large 
that it was blocked and awaits moderation.

Once / if the moderator confirms it, it should appear here on the list.


Thanks and best regards,

 ? Gunter



From shade at redhat.com  Mon Jul  5 08:35:30 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 5 Jul 2021 10:35:30 +0200
Subject: [8u] RFR (S) 8194246: JVM crashes when calling getStackTrace if stack
 contains a method that is a member of a very large class
Message-ID: <e52d0aef-c2b4-22df-fd90-2ef55cb53dda@redhat.com>

Original bug:
   https://bugs.openjdk.java.net/browse/JDK-8194246
   https://hg.openjdk.java.net/jdk/jdk/rev/f01f81fa1242

The patch does not apply cleanly to 8u, because the context is different due to stack trace handling 
rewrites in 9 (mostly for StackWalker, AFAICS). I reapplied the patch by hand for every access to 
_method array. Note that _cprefs seems to have the similar problem, but it does not have a tested 
upstream patch, so I deferred that to JDK-8269859.

Plus, test requires small adjustments for /testlibrary, imports, and dropping the class file version 
to 52.0.

8u webrev:
   https://cr.openjdk.java.net/~shade/8194246/webrev.8u.01/

Testing: new test (used to fail, now passes); tier1

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Jul  5 09:24:20 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 5 Jul 2021 11:24:20 +0200
Subject: [8u] RFR: 8269810: [8u] Update generated_configure.sh after
 JDK-8250876 backport
In-Reply-To: <494095e11ecca871b3cf5561eea351e153bd78d4.camel@redhat.com>
References: <494095e11ecca871b3cf5561eea351e153bd78d4.camel@redhat.com>
Message-ID: <75c45bfa-3118-4a48-3d0f-b8d948ef0b6a@redhat.com>

On 7/2/21 3:07 PM, Severin Gehwolf wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8269810
> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8269810/01/webrev/
> 
> Thoughts?

Looks fine to me, assuming it was fully auto-generated.

-- 
Thanks,
-Aleksey


From sgehwolf at redhat.com  Mon Jul  5 09:43:21 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 05 Jul 2021 11:43:21 +0200
Subject: [8u] RFR: 8269810: [8u] Update generated_configure.sh after
 JDK-8250876 backport
In-Reply-To: <75c45bfa-3118-4a48-3d0f-b8d948ef0b6a@redhat.com>
References: <494095e11ecca871b3cf5561eea351e153bd78d4.camel@redhat.com>
 <75c45bfa-3118-4a48-3d0f-b8d948ef0b6a@redhat.com>
Message-ID: <dd981acf8916e9888d2be854b2b4da091f5dc001.camel@redhat.com>

On Mon, 2021-07-05 at 11:24 +0200, Aleksey Shipilev wrote:
> On 7/2/21 3:07 PM, Severin Gehwolf wrote:
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8269810
> > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8269810/01/webrev/
> > 
> > Thoughts?
> 
> Looks fine to me, assuming it was fully auto-generated.
> 

It was, yes. Thanks for the review!

Cheers,
Severin


From mails.mail.openjdk.java.net at gunter.ohrner.net  Mon Jul  5 10:04:20 2021
From: mails.mail.openjdk.java.net at gunter.ohrner.net (Gunter Ohrner)
Date: Mon, 5 Jul 2021 12:04:20 +0200
Subject: =?UTF-8?Q?Re=3A_OpenJDK_8_292_=28and212=29SIGSEGVinInstanceKlass=3A=3A?=
 =?UTF-8?Q?method=5Fwith=5Forig=5Fidnum?=
In-Reply-To: <3c7b1bab-870d-aa90-aa63-00063927b9e7@ohrner.net>
References: <e55a5a51-e638-737f-8b9a-50dc87b6ae83@ohrner.net>
 <e2a83cfd-9907-4350-0577-4fadb660bae2@redhat.com>
 <3c7b1bab-870d-aa90-aa63-00063927b9e7@ohrner.net>
Message-ID: <17144a8f-8942-3c93-00a7-e0a5e983af08@ohrner.net>

Am 05.07.21 um 09:29 schrieb Gunter Ohrner:
> Am 05.07.21 um 09:22 schrieb Aleksey Shipilev:
>> On 7/4/21 4:48 PM, Gunter Ohrner wrote:
>>> It's consistently reproducable on one Debian 10 "Buster" x64 machine
>>> with as well AdoptOpenJDK-build 1.8.0 292? and Amazon Corretto builds
>>> 1.8.0 292 and 212 (always with the same stack trace).
>>
>> Could you please run with fastdebug build and say if it fails with 
>> the assert? You can try a fastdebug build from here:
>> ? https://builds.shipilev.net/openjdk-jdk8-dev/
> Ok, will try.

Here's the output of the fastdebug build:


# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:? SuppressErrorAt=/array.hpp:383
#
# A fatal error has been detected by the Java Runtime Environment:
#
#? Internal Error 
(/home/buildbot/worker/build-jdk8u-dev-linux/build/hotspot/src/share/vm/utilities/array.hpp:383), 
pid=38746, tid=0x00007f5b3d3c3700
#? assert(i >= 0 && i< _length) failed: oob: 0 <= -32023 < 33514
#
# JRE version: OpenJDK Runtime Environment (8.0) (build 
1.8.0-builds.shipilev.net-openjdk-jdk8-dev-b432-20210625-fastdebug-testing-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode 
linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable 
core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /var/tmp/XDISAllTestsContinuously/api/hs_err_pid38746.log
#
# If you would like to submit a bug report, please visit:
#?? http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 140029846107904
Dumping core ...


Best regards,

 ? Gunter



From sgehwolf at redhat.com  Mon Jul  5 10:06:33 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 05 Jul 2021 12:06:33 +0200
Subject: [8u] RFR (S) 8194246: JVM crashes when calling getStackTrace if
 stack contains a method that is a member of a very large class
In-Reply-To: <e52d0aef-c2b4-22df-fd90-2ef55cb53dda@redhat.com>
References: <e52d0aef-c2b4-22df-fd90-2ef55cb53dda@redhat.com>
Message-ID: <61a0da35ac16919ca0b690ddbd3bedc3b46830fe.camel@redhat.com>

On Mon, 2021-07-05 at 10:35 +0200, Aleksey Shipilev wrote:
> 8u webrev:
> ?? https://cr.openjdk.java.net/~shade/8194246/webrev.8u.01/

This looks OK to me.

Thanks,
Severin


From shade at redhat.com  Mon Jul  5 10:09:57 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 5 Jul 2021 12:09:57 +0200
Subject: [8u] RFR (S) 8194246: JVM crashes when calling getStackTrace if
 stack contains a method that is a member of a very large class
In-Reply-To: <61a0da35ac16919ca0b690ddbd3bedc3b46830fe.camel@redhat.com>
References: <e52d0aef-c2b4-22df-fd90-2ef55cb53dda@redhat.com>
 <61a0da35ac16919ca0b690ddbd3bedc3b46830fe.camel@redhat.com>
Message-ID: <6b4a93ef-e729-8569-5573-ecf31f76a920@redhat.com>

On 7/5/21 12:06 PM, Severin Gehwolf wrote:
> On Mon, 2021-07-05 at 10:35 +0200, Aleksey Shipilev wrote:
>> 8u webrev:
>>  ?? https://cr.openjdk.java.net/~shade/8194246/webrev.8u.01/
> 
> This looks OK to me.

Thanks, tagged for approval.

-- 
-Aleksey


From shade at redhat.com  Mon Jul  5 10:13:04 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 5 Jul 2021 12:13:04 +0200
Subject: OpenJDK 8 292
 (and212)SIGSEGVinInstanceKlass::method_with_orig_idnum
In-Reply-To: <17144a8f-8942-3c93-00a7-e0a5e983af08@ohrner.net>
References: <e55a5a51-e638-737f-8b9a-50dc87b6ae83@ohrner.net>
 <e2a83cfd-9907-4350-0577-4fadb660bae2@redhat.com>
 <3c7b1bab-870d-aa90-aa63-00063927b9e7@ohrner.net>
 <17144a8f-8942-3c93-00a7-e0a5e983af08@ohrner.net>
Message-ID: <52027324-b3d9-70a9-f066-3f24651f858a@redhat.com>

On 7/5/21 12:04 PM, Gunter Ohrner wrote:
> #? Internal Error
> (/home/buildbot/worker/build-jdk8u-dev-linux/build/hotspot/src/share/vm/utilities/array.hpp:383),
> pid=38746, tid=0x00007f5b3d3c3700
> #? assert(i >= 0 && i< _length) failed: oob: 0 <= -32023 < 33514
> #

Yeah, that looks like https://bugs.openjdk.java.net/browse/JDK-8194246 -- on a hunch, I did the 8u 
backport due diligence this morning, and now the fix waits for 8u maintainers approval.

-- 
Thanks,
-Aleksey


From mails.mail.openjdk.java.net at gunter.ohrner.net  Mon Jul  5 10:37:40 2021
From: mails.mail.openjdk.java.net at gunter.ohrner.net (Gunter Ohrner)
Date: Mon, 5 Jul 2021 12:37:40 +0200
Subject: =?UTF-8?Q?Re=3A_OpenJDK_8292=28and212=29SIGSEGVinInstanceKlass=3A=3A?=
 =?UTF-8?Q?method=5Fwith=5Forig=5Fidnum?=
In-Reply-To: <52027324-b3d9-70a9-f066-3f24651f858a@redhat.com>
References: <e55a5a51-e638-737f-8b9a-50dc87b6ae83@ohrner.net>
 <e2a83cfd-9907-4350-0577-4fadb660bae2@redhat.com>
 <3c7b1bab-870d-aa90-aa63-00063927b9e7@ohrner.net>
 <17144a8f-8942-3c93-00a7-e0a5e983af08@ohrner.net>
 <52027324-b3d9-70a9-f066-3f24651f858a@redhat.com>
Message-ID: <040b0313-fc8e-38e6-3fbf-3974f5fc0401@ohrner.net>

Am 05.07.21 um 12:13 schrieb Aleksey Shipilev:
> On 7/5/21 12:04 PM, Gunter Ohrner wrote:
>> #? Internal Error
>> (/home/buildbot/worker/build-jdk8u-dev-linux/build/hotspot/src/share/vm/utilities/array.hpp:383), 
>>
>> pid=38746, tid=0x00007f5b3d3c3700
>> #? assert(i >= 0 && i< _length) failed: oob: 0 <= -32023 < 33514
>> #
>
> Yeah, that looks like https://bugs.openjdk.java.net/browse/JDK-8194246 
> -- on a hunch, I did the 8u backport due diligence this morning, and 
> now the fix waits for 8u maintainers approval

So my options would be to

a) wait for a fixed u release

b) avoid an Exception to happen in this situation


Still wondering a bit what changed - the code itself is not too new, but 
I recently switched from an ant-based build to a Gradle based build system.

Does Gradle introduce classes with overly many methods into the call 
stack? All other classes on the stack should already have been there 
before...

It also doesn't seem to crash on Windows machines with a Windows jvm 
(same JVM version), and it seemed to work with the same JVM version in 
Ubuntu 20.04 (instead of Debian Buster or Bullseye, but there might be 
additional factors behind the crash).


Best regards,

 ? Gunter


From shade at redhat.com  Mon Jul  5 13:10:54 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 5 Jul 2021 15:10:54 +0200
Subject: OpenJDK 8292(and212)SIGSEGVinInstanceKlass::method_with_orig_idnum
In-Reply-To: <040b0313-fc8e-38e6-3fbf-3974f5fc0401@ohrner.net>
References: <e55a5a51-e638-737f-8b9a-50dc87b6ae83@ohrner.net>
 <e2a83cfd-9907-4350-0577-4fadb660bae2@redhat.com>
 <3c7b1bab-870d-aa90-aa63-00063927b9e7@ohrner.net>
 <17144a8f-8942-3c93-00a7-e0a5e983af08@ohrner.net>
 <52027324-b3d9-70a9-f066-3f24651f858a@redhat.com>
 <040b0313-fc8e-38e6-3fbf-3974f5fc0401@ohrner.net>
Message-ID: <f345c1bd-63d8-75c2-babc-44fff8f0ab2a@redhat.com>

On 7/5/21 12:37 PM, Gunter Ohrner wrote:
> Am 05.07.21 um 12:13 schrieb Aleksey Shipilev:
>> On 7/5/21 12:04 PM, Gunter Ohrner wrote:
>>> #? Internal Error
>>> (/home/buildbot/worker/build-jdk8u-dev-linux/build/hotspot/src/share/vm/utilities/array.hpp:383),
>>>
>>> pid=38746, tid=0x00007f5b3d3c3700
>>> #? assert(i >= 0 && i< _length) failed: oob: 0 <= -32023 < 33514
>>> #
>>
>> Yeah, that looks like https://bugs.openjdk.java.net/browse/JDK-8194246
>> -- on a hunch, I did the 8u backport due diligence this morning, and
>> now the fix waits for 8u maintainers approval
> 
> So my options would be to
> 
> a) wait for a fixed u release

Yes, assuming that was the issue. I would like to ask you to run with the new nightly binary to 
confirm. Anyhow, unfortunately, it is too late to fix for July release, and so it would have to wait 
for October.

> b) avoid an Exception to happen in this situation
> Does Gradle introduce classes with overly many methods into the call
> stack? All other classes on the stack should already have been there
> before...

Hard to guess. I would suspect that the generated code shape depends on the environment. If you were 
able to build the OpenJDK by yourself, you could probably print out the problematic class name on 
the failing path.

There is also another option:

  c) Migrate to 11u that has this fix already; not sure how viable is that for you.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Jul  5 13:14:44 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 5 Jul 2021 15:14:44 +0200
Subject: OpenJDK 8292(and212)SIGSEGVinInstanceKlass::method_with_orig_idnum
In-Reply-To: <f345c1bd-63d8-75c2-babc-44fff8f0ab2a@redhat.com>
References: <e55a5a51-e638-737f-8b9a-50dc87b6ae83@ohrner.net>
 <e2a83cfd-9907-4350-0577-4fadb660bae2@redhat.com>
 <3c7b1bab-870d-aa90-aa63-00063927b9e7@ohrner.net>
 <17144a8f-8942-3c93-00a7-e0a5e983af08@ohrner.net>
 <52027324-b3d9-70a9-f066-3f24651f858a@redhat.com>
 <040b0313-fc8e-38e6-3fbf-3974f5fc0401@ohrner.net>
 <f345c1bd-63d8-75c2-babc-44fff8f0ab2a@redhat.com>
Message-ID: <4e89f76c-e704-7b23-4c0d-a0db7729e149@redhat.com>

On 7/5/21 3:10 PM, Aleksey Shipilev wrote:
>> a) wait for a fixed u release
> 
> Yes, assuming that was the issue. I would like to ask you to run with the new nightly binary to
> confirm. 

...*after* the fix is in. It is not yet in.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Jul  5 18:06:49 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 5 Jul 2021 20:06:49 +0200
Subject: [8u] RFR (XS) 8269859: BacktraceBuilder._cprefs needs to be accessed
 as unsigned short
Message-ID: <52931740-f90a-dd28-9fc6-3c5fd40c4880@redhat.com>

Bug:
   https://bugs.openjdk.java.net/browse/JDK-8269859

This is a 8u-specific bug that I found with source code inspection while working on a related 
backport. With unmodified JDK, it is hard to reproduce, because it involves large class that 
undergoes redefinition. Yet, with a simple VM change, you can reproduce the assert 100% reliably.

See the bug report for more details.

8u webrev:
   https://cr.openjdk.java.net/~shade/8269859/webrev.8u.01/

Testing: test from 8194246 with/without the fix, with/without the cpref-exposing patch; tier1 
with/without the cpref-exposing patch.

-- 
Thanks,
-Aleksey


From alexey at azul.com  Tue Jul  6 09:36:12 2021
From: alexey at azul.com (Alexey Bakhtin)
Date: Tue, 6 Jul 2021 09:36:12 +0000
Subject: [PING] [8u] RFR: 8214418 half-closed SSLEngine status may cause
 application dead loop
In-Reply-To: <TYAPR01MB251158064123D032C0DBA926E7359@TYAPR01MB2511.jpnprd01.prod.outlook.com>
References: <TYAPR01MB2511B9C23663014FA1C0EB40E7389@TYAPR01MB2511.jpnprd01.prod.outlook.com>
 <20210609035732.GB26136@rincewind>
 <TYAPR01MB251158064123D032C0DBA926E7359@TYAPR01MB2511.jpnprd01.prod.outlook.com>
Message-ID: <A3E9BFD9-828E-4B97-868A-89F3A905A497@azul.com>

Hello Takuya,

11u patch is applied clean and 8u backport is approved in https://bugs.openjdk.java.net/browse/JDK-8241054
If you don?t mind I can push the fix with original author and reviewers

Regards
Alexey

> On 10 Jun 2021, at 11:50, kiriyama.takuya at fujitsu.com wrote:
> 
> Hi Andrew,
> 
> Thank you for your reply.
> 
>> Please post the patch for review and I can handle the JBS side for you.
> 
> Please consider the following code:
> 
> diff -r -u a/src/share/classes/sun/security/ssl/Ciphertext.java b/src/share/classes/sun/security/ssl/Ciphertext.java
> --- a/src/share/classes/sun/security/ssl/Ciphertext.java	2021-06-09 21:26:26.762180800 +0900
> +++ b/src/share/classes/sun/security/ssl/Ciphertext.java	2021-06-10 09:00:33.660574600 +0900
> @@ -31,7 +31,6 @@
>  * Ciphertext
>  */
> final class Ciphertext {
> -    static final Ciphertext CIPHERTEXT_NULL = new Ciphertext();
> 
>     final byte contentType;
>     final byte handshakeType;
> diff -r -u a/src/share/classes/sun/security/ssl/SSLEngineImpl.java b/src/share/classes/sun/security/ssl/SSLEngineImpl.java
> --- a/src/share/classes/sun/security/ssl/SSLEngineImpl.java	2021-06-09 21:26:26.763148800 +0900
> +++ b/src/share/classes/sun/security/ssl/SSLEngineImpl.java	2021-06-10 09:19:42.665488000 +0900
> @@ -227,6 +227,19 @@
>             hsStatus = ciphertext.handshakeStatus;
>         } else {
>             hsStatus = getHandshakeStatus();
> +            if (ciphertext == null && !conContext.isNegotiated &&
> +                    conContext.isInboundClosed() &&
> +                    hsStatus == HandshakeStatus.NEED_WRAP) {
> +                // Even the outboud is open, no futher data could be wrapped as:
> +                //     1. the outbound is empty
> +                //     2. no negotiated connection
> +                //     3. the inbound has closed, cannot complete the handshake
> +                //
> +                // Mark the engine as closed if the handshake status is
> +                // NEED_WRAP. Otherwise, it could lead to dead loops in
> +                // applications.
> +                status = Status.CLOSED;
> +            }
>         }
> 
>         int deltaSrcs = srcsRemains;
> @@ -258,7 +271,7 @@
>         }
> 
>         if (ciphertext == null) {
> -            return Ciphertext.CIPHERTEXT_NULL;
> +            return null;
>         }
> 
>         // Is the handshake completed?
> diff -r -u a/src/share/classes/sun/security/ssl/TransportContext.java b/src/share/classes/sun/security/ssl/TransportContext.java
> --- a/src/share/classes/sun/security/ssl/TransportContext.java	2021-06-09 21:26:26.766062300 +0900
> +++ b/src/share/classes/sun/security/ssl/TransportContext.java	2021-06-10 09:14:04.842253500 +0900
> @@ -577,13 +577,7 @@
>                 // Special case that the inbound was closed, but outbound open.
>                 return HandshakeStatus.NEED_WRAP;
>             }
> -        } else if (isOutboundClosed() && !isInboundClosed()) {
> -            // Special case that the outbound was closed, but inbound open.
> -            return HandshakeStatus.NEED_UNWRAP;
> -        } else if (!isOutboundClosed() && isInboundClosed()) {
> -            // Special case that the inbound was closed, but outbound open.
> -            return HandshakeStatus.NEED_WRAP;
> -        }
> +        }   // Otherwise, both inbound and outbound are closed
> 
>         return HandshakeStatus.NOT_HANDSHAKING;
>     }
> 
>> I am confused with what you mean about the copyright year as
>> 
>> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/6852be0de227
>> 
>> contains no copyright year changes.
> 
> I'm sorry, I was mistaken.
> It contains no copyright year changes.
> 
> Regards,
> Takuya Kiriyama
> 
>> -----Original Message-----
>> From: Andrew Hughes <gnu.andrew at redhat.com>
>> Sent: Wednesday, June 9, 2021 12:58 PM
>> To: Kiriyama, Takuya/?? ?? <kiriyama.takuya at fujitsu.com>
>> Cc: 'jdk8u-dev at openjdk.java.net' <jdk8u-dev at openjdk.java.net>
>> Subject: Re: [PING] RE: [8u] RFR: 8214418 half-closed SSLEngine status
>> may cause application dead loop
>> 
>> On 08:59 Mon 07 Jun     , kiriyama.takuya at fujitsu.com wrote:
>>> Hello,
>>> 
>>> Please reply if anyone can be a sponsor.
>>> 
>>> Regards,
>>> Takuya Kiriyama
>>> 
>>>> -----Original Message-----
>>>> From: Kiriyama, Takuya/?? ??
>>>> Sent: Monday, May 31, 2021 5:58 PM
>>>> To: 'jdk8u-dev at openjdk.java.net' <jdk8u-dev at openjdk.java.net>
>>>> Subject: [8u] RFR: 8214418 half-closed SSLEngine status may cause
>>>> application dead loop
>>>> 
>>>> Hi all,
>>>> 
>>>> The problem reported by JDK-8214418 occurs on JDK8.
>>>> I would like to backport 8214418 patch to 8u. But I don't have a JBS
>> account.
>>>> Could anybody help me as a sponsor of this backporting ?
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8214418
>>>> https://hg.openjdk.java.net/jdk/jdk/rev/5022a4915fe9
>>>> 
>>>> I don't have access permission to
>>>> https://bugs.openjdk.java.net/browse/JDK-8214418.
>> 
>> Neither do I. It looks like the bug is closed. We'll use 8241054 instead.
>> 
>>>> I can confirm that 8214418 has been backported to JDK11.
>>>> https://bugs.openjdk.java.net/browse/JDK-8241054
>>>> https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/6852be0de227
>>>> 
>>>> Original patch applied almost clean except for copyright year.
>>>> I have confirmed that the problem does not occur after backporting with
>> 8u.
>> 
>> Please post the patch for review and I can handle the JBS side for you.
>> 
>> I am confused with what you mean about the copyright year as
>> 
>> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/6852be0de227
>> 
>> contains no copyright year changes.
>> 
>>>> 
>>>> Regards,
>>>> Takuya Kiriyama
>>> 
>> 
>> 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


From shade at redhat.com  Tue Jul  6 12:07:26 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 6 Jul 2021 14:07:26 +0200
Subject: [8u] RFR (S) 8065215: Print warning summary at end of configure
In-Reply-To: <f0bd53cf29ef707922265d707ad2c2448e09940b.camel@redhat.com>
References: <43a6cc4b-a735-8d1f-45d2-714c9ed64145@redhat.com>
 <f0bd53cf29ef707922265d707ad2c2448e09940b.camel@redhat.com>
Message-ID: <1631bc8e-291d-ffeb-75b6-445b500f4eaa@redhat.com>

On 7/2/21 5:19 PM, Severin Gehwolf wrote:
> On Tue, 2021-04-27 at 11:52 +0200, Aleksey Shipilev wrote:
>> Original RFE:
>>  ?? https://bugs.openjdk.java.net/browse/JDK-8065215
>>  ?? https://hg.openjdk.java.net/jdk9/jdk9/rev/eefa97d0d263
>>
>> I would like to backport this 8u build system change to improve error detection during configure.
>> This also allows cleaner backport of JDK-8079891.
>>
>> The patch has a few minor differences:
>>  ?? *) There is no CUSTOM_SUMMARY_AND_WARNINGS_HOOK, no configure.ac hunk does not apply automatically;
>>  ?? *) There are no relevant "has been successfully created" blocks in help.m4;
>>  ?? *) generated-configure.sh is obviously different;
>>
>> 8u webrev:
>>  ?? https://cr.openjdk.java.net/~shade/8065215/webrev.8u.01/
> 
> This looks OK to me. Note that generated_configure.sh needs to get re-
> generated. Currently the 8u-dev tree is out of sync (see JDK-8269810).

Right. Regenerated after JDK-8269810:
   https://cr.openjdk.java.net/~shade/8065215/webrev.8u.02

I tagged the fix for approvals.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Jul  6 12:10:04 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 6 Jul 2021 14:10:04 +0200
Subject: [8u] RFR (S) 8079891: Store configure log in $BUILD/configure.log
In-Reply-To: <354dc4caea576aff2d97e8d1dceedb9156e9197c.camel@redhat.com>
References: <b3a2c022-97c7-1d6d-64ec-e79c8132194e@redhat.com>
 <354dc4caea576aff2d97e8d1dceedb9156e9197c.camel@redhat.com>
Message-ID: <681a1ca0-1e45-e7dd-36f8-3ec395b4b97d@redhat.com>

On 7/2/21 5:21 PM, Severin Gehwolf wrote:
> On Tue, 2021-04-27 at 12:01 +0200, Aleksey Shipilev wrote:
>> Original RFE:
>>  ?? https://bugs.openjdk.java.net/browse/JDK-8079891
>>  ?? https://hg.openjdk.java.net/jdk9/jdk9/rev/98e85b507b09
>>
>> I would like to have this simple build feature in 8u to better report configuration logs from 8u
>> CIs. This patch applies mostly trivially, with the following changes:
>>  ?? *) Blocks mentioning CONFIGURESUPPORT_OUTPUTDIR are removed, as these are not relevant to 8u
>> build system;
>>  ?? *) Minor contextual conflicts are resolved;
>>
>> Current patch needs JDK-8065215 applied first to get the help block at the end of configure. This
>> also needs JDK-8080082 as the follow-up.
>>
>> Testing: 8u build; observing configure.log in build artifacts
> 
> Missing a link to the webrev?

Right, sorry.

Here it is (regenerated for the 8u state after JDK-8065215):
  https://cr.openjdk.java.net/~shade/8079891/webrev.8u.02/

-- 
Thanks,
-Aleksey


From thomas.stuefe at gmail.com  Tue Jul  6 12:36:50 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 6 Jul 2021 14:36:50 +0200
Subject: [8u] RFR: JDK-8220786: Create new switch to redirect error
 reporting output to stdout or stderr
In-Reply-To: <537B865D-823E-4FC2-8FED-90EE8B0D403E@amazon.com>
References: <537B865D-823E-4FC2-8FED-90EE8B0D403E@amazon.com>
Message-ID: <CAA-vtUw5WJ_15Ov4++x9QwKtN7sKsOGvpbGcsddNLdTqEhCFBg@mail.gmail.com>

Hi,

just chiming in from the side. I agree that this is an error and should be
fixed in head. But I honestly think the error is rather benign. The error
would cause an error log file that happens to have the numerical fd=3 to be
not closed. But we are going to abort(3) anyway, which will properly close
that file descriptor. Also, the chance to even get that fd is
astronomically low.

I personally would just go ahead with the downport and let the second fix
trickle through later, but of course that is not up to me.

Cheers, Thomas


On Wed, Jun 2, 2021 at 1:19 AM Hohensee, Paul <hohensee at amazon.com> wrote:

> Also looks to me like the test in vmError.cpp should be "> 2" rather than
> "> 3". The original review thread
>
>
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-March/033293.html
>
> has no discussion of why it's 3 instead of 2, but, since "> 3" is in tip,
> I'd rather keep "> 3" in this backport, fix it in tip, then backport the
> fix to 11u and 8u. It needs to be fixed in tip and 11u anyway, and doing it
> the formal way will keep things organized.
>
> Otherwise lgtm.
>
> Thanks,
> Paul
>
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Volker
> Simonis <volker.simonis at gmail.com>
> Date: Tuesday, June 1, 2021 at 12:37 PM
> To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject: [8u] RFR: JDK-8220786: Create new switch to redirect error
> reporting output to stdout or stderr
>
> Hi,
>
> can I please get a review for this backport?
>
> This change initially went into jdk 13 and has already been downported
> to jdk 11u more than a year ago. But as jdk8u is still used a lot and
> increasingly in containerized environments I think it still makes a
> lot of sense to downport it to jdk 8u as well.
>
> If the JVM crashes in a containerized environment with its ephemeral
> file system it becomes impossible to do any post mortem analysis of
> the problem. In such situations the ability to dump the hs_err file to
> stdout/stderr is very useful, because many container environments log
> the stdout/stderr stream by default.
>
> Original issue: https://bugs.openjdk.java.net/browse/JDK-8220786
> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8220787
> Original change: http://hg.openjdk.java.net/jdk/jdk/rev/cf75ea6af695
>
> jdk11 backport: https://bugs.openjdk.java.net/browse/JDK-8238531
> jdk11 CSR: https://bugs.openjdk.java.net/browse/JDK-8238532
> jdk11 change:
> https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/783a56f3ac1f
>
> jdk8 backport: https://bugs.openjdk.java.net/browse/JDK-8268055
> jdk8 CSR: https://bugs.openjdk.java.net/browse/JDK-8268058
> jdk8 webrev:
> http://cr.openjdk.java.net/~simonis/webrevs/2021/8220786-jdk8u/
>
> I had to do quite some, but trivial changes to the jdk 11 backport
> (which I started with) to fit it into jdk 8u:
>
> arguments.cpp
> -------------------
> In jdk 11 "FLAG_SET_CMDLINE(boolean, ...)" expands to "JVMFlag::Error
> boolAtPut(JVMFlagsWithType flag, bool value, JVMFlag::Flags origin)"
> which returns a "JVMFlag::Error" and can be checked for success. In
> jdk 8,  "FLAG_SET_CMDLINE(boolean, ...)" expands to "void
> boolAtPut(CommandLineFlagWithType flag, bool value, Flag::Flags
> origin)" which returns void, so there's nothing to check for...
>
> vmError.cpp
> ----------------
> I think the initial implementation has a bug in the following code:
>
> -    if (fd_log != -1) {
> +    if (fd_log > 3) {
>        close(fd_log);
>
> I think the intention is to close the log stream if it was not stdout
> (i.e. "1") or stderr (i.e. "2") but it checks for "fd_log > 3".
>
> I've fixed this in the downport but I'm happy to revert the fix if
> somebody has a good explanation for the original code:
>
> -    if (log.fd() != defaultStream::output_fd()) {
> +    if (log.fd() > 2) {
>
> ErrorFileRedirectTest.java
> ---------------------------------
> - path/package shuffling for the test library
> - use "Platform.isDebugBuild()" instead of "@requires (vm.debug ==
> true)" which is not supported in jdk8
> - remove "-XX:-CreateCoredumpOnCrash" option because it doesn't exist in
> jdk 8
> - use "-XX:ErrorHandlerTest=12" instead of "-XX:ErrorHandlerTest=14"
> because "14" is not available in jdk 8. But "12" still generates a
> SIGSEV by reading from memory address 0.
> - check for "T H R E A D" in the output because jdk 8 has no "S U M M
> A R Y" section.
>
> The jdk 8 CSR (https://bugs.openjdk.java.net/browse/JDK-8268058) has
> been reviewed and waits for approval.
>
> Thank you and best regards,
> Volker
>
>

From sgehwolf at redhat.com  Tue Jul  6 12:57:41 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 06 Jul 2021 14:57:41 +0200
Subject: [8u] RFR (S) 8079891: Store configure log in $BUILD/configure.log
In-Reply-To: <681a1ca0-1e45-e7dd-36f8-3ec395b4b97d@redhat.com>
References: <b3a2c022-97c7-1d6d-64ec-e79c8132194e@redhat.com>
 <354dc4caea576aff2d97e8d1dceedb9156e9197c.camel@redhat.com>
 <681a1ca0-1e45-e7dd-36f8-3ec395b4b97d@redhat.com>
Message-ID: <90ee312df9f0a389d8078c71223cf5db18babbe0.camel@redhat.com>

On Tue, 2021-07-06 at 14:10 +0200, Aleksey Shipilev wrote:
> On 7/2/21 5:21 PM, Severin Gehwolf wrote:
> > On Tue, 2021-04-27 at 12:01 +0200, Aleksey Shipilev wrote:
> > > Original RFE:
> > > ??? https://bugs.openjdk.java.net/browse/JDK-8079891
> > > ??? https://hg.openjdk.java.net/jdk9/jdk9/rev/98e85b507b09
> > > 
> > > I would like to have this simple build feature in 8u to better report configuration logs from 8u
> > > CIs. This patch applies mostly trivially, with the following changes:
> > > ??? *) Blocks mentioning CONFIGURESUPPORT_OUTPUTDIR are removed, as these are not relevant to 8u
> > > build system;
> > > ??? *) Minor contextual conflicts are resolved;
> > > 
> > > Current patch needs JDK-8065215 applied first to get the help block at the end of configure. This
> > > also needs JDK-8080082 as the follow-up.
> > > 
> > > Testing: 8u build; observing configure.log in build artifacts
> > 
> > Missing a link to the webrev?
> 
> Right, sorry.
> 
> Here it is (regenerated for the 8u state after JDK-8065215):
> ? https://cr.openjdk.java.net/~shade/8079891/webrev.8u.02/

This looks mostly fine. One thing stood out:

common/autoconf/configure.ac

 270 # Make the compare script executable
 271 $CHMOD +x $OUTPUT_ROOT/compare.sh
 272 

These lines are removed in the original patch[1]. As they are, after
patch, in BASIC_POST_CONFIG_OUTPUT anyway, we should also remove.

Thanks,
Severin

[1] https://hg.openjdk.java.net/jdk9/jdk9/rev/98e85b507b09#l3.16


From shade at redhat.com  Tue Jul  6 13:04:44 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 6 Jul 2021 15:04:44 +0200
Subject: [8u] RFR (S) 8079891: Store configure log in $BUILD/configure.log
In-Reply-To: <90ee312df9f0a389d8078c71223cf5db18babbe0.camel@redhat.com>
References: <b3a2c022-97c7-1d6d-64ec-e79c8132194e@redhat.com>
 <354dc4caea576aff2d97e8d1dceedb9156e9197c.camel@redhat.com>
 <681a1ca0-1e45-e7dd-36f8-3ec395b4b97d@redhat.com>
 <90ee312df9f0a389d8078c71223cf5db18babbe0.camel@redhat.com>
Message-ID: <34338b6a-2ab1-be3b-b960-e6d7c0cc031d@redhat.com>

On 7/6/21 2:57 PM, Severin Gehwolf wrote:
>> Here it is (regenerated for the 8u state after JDK-8065215):
>>  ? https://cr.openjdk.java.net/~shade/8079891/webrev.8u.02/
> 
> This looks mostly fine. One thing stood out:
> 
> common/autoconf/configure.ac
> 
>   270 # Make the compare script executable
>   271 $CHMOD +x $OUTPUT_ROOT/compare.sh
>   272
> 
> These lines are removed in the original patch[1]. As they are, after
> patch, in BASIC_POST_CONFIG_OUTPUT anyway, we should also remove.

Oh right, good catch. I had a weird conflict in those hunks, which I resolved with incorrectly 
leaving the $CHMOD line in.

Fixed and regenerated generated-configure.sh:
   https://cr.openjdk.java.net/~shade/8079891/webrev.8u.03/

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Jul  6 13:22:26 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 6 Jul 2021 15:22:26 +0200
Subject: [8u] RFR (XS) 8080082: configure fails if you create an empty
 directory and then run configure from it
In-Reply-To: <9d7d10f873b82fb6f2dc714f911f5fa5569e7762.camel@redhat.com>
References: <c76a0a8e-3638-7163-cfbe-70992f8d2500@redhat.com>
 <9d7d10f873b82fb6f2dc714f911f5fa5569e7762.camel@redhat.com>
Message-ID: <dfa303a8-1ed2-a865-840c-5c66daf85325@redhat.com>

On 7/2/21 5:29 PM, Severin Gehwolf wrote:
> On Tue, 2021-04-27 at 12:09 +0200, Aleksey Shipilev wrote:
>> 8u webrev:
>>  ?? https://cr.openjdk.java.net/~shade/8080082/webrev.8u.01/
> 
> LGTM. Please generate configure from scratch before you push.

Yes, of course. I tagged the issue for approval.

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Tue Jul  6 13:27:58 2021
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 6 Jul 2021 09:27:58 -0400
Subject: [8u] RFR 8269594: assert(_handle_mark_nesting > 1) failed: memory
 leak: allocating handle outside HandleMark
Message-ID: <1dcac47c-a56c-03e2-2ae0-edf2dd06cae7@redhat.com>

I would like to backport this low risk and single line patch to 8u to 
fix potential hard-to-find memory leak.

Bug: https://bugs.openjdk.java.net/browse/JDK-8269594
Patch: 
https://github.com/openjdk/jdk17/commit/4b4bef4e1e06c8efbfeb2c28e0658ce91ee9ad66

The original patch does not apply cleanly, due to undefined "self" 
variable, changed to "thread()" instead.

8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8269594-8u/webrev.00/


Thanks,

-Zhengyu


From sgehwolf at redhat.com  Tue Jul  6 13:30:27 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 06 Jul 2021 15:30:27 +0200
Subject: [8u] RFR (S) 8079891: Store configure log in $BUILD/configure.log
In-Reply-To: <34338b6a-2ab1-be3b-b960-e6d7c0cc031d@redhat.com>
References: <b3a2c022-97c7-1d6d-64ec-e79c8132194e@redhat.com>
 <354dc4caea576aff2d97e8d1dceedb9156e9197c.camel@redhat.com>
 <681a1ca0-1e45-e7dd-36f8-3ec395b4b97d@redhat.com>
 <90ee312df9f0a389d8078c71223cf5db18babbe0.camel@redhat.com>
 <34338b6a-2ab1-be3b-b960-e6d7c0cc031d@redhat.com>
Message-ID: <f64ef5941ed3982f6bcdfcfee647ba6d6bd12436.camel@redhat.com>

On Tue, 2021-07-06 at 15:04 +0200, Aleksey Shipilev wrote:
> Fixed and regenerated generated-configure.sh:
> ?? https://cr.openjdk.java.net/~shade/8079891/webrev.8u.03/

Thanks, looks good.

Cheers,
Severin


From shade at redhat.com  Tue Jul  6 13:33:44 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 6 Jul 2021 15:33:44 +0200
Subject: [8u] RFR (S) 8079891: Store configure log in $BUILD/configure.log
In-Reply-To: <f64ef5941ed3982f6bcdfcfee647ba6d6bd12436.camel@redhat.com>
References: <b3a2c022-97c7-1d6d-64ec-e79c8132194e@redhat.com>
 <354dc4caea576aff2d97e8d1dceedb9156e9197c.camel@redhat.com>
 <681a1ca0-1e45-e7dd-36f8-3ec395b4b97d@redhat.com>
 <90ee312df9f0a389d8078c71223cf5db18babbe0.camel@redhat.com>
 <34338b6a-2ab1-be3b-b960-e6d7c0cc031d@redhat.com>
 <f64ef5941ed3982f6bcdfcfee647ba6d6bd12436.camel@redhat.com>
Message-ID: <01e078ae-8045-1bf4-aca6-39b81857ba84@redhat.com>

On 7/6/21 3:30 PM, Severin Gehwolf wrote:
> On Tue, 2021-07-06 at 15:04 +0200, Aleksey Shipilev wrote:
>> Fixed and regenerated generated-configure.sh:
>>  ?? https://cr.openjdk.java.net/~shade/8079891/webrev.8u.03/
> 
> Thanks, looks good.

Cheers, tagged for approvals.

-- 
-Aleksey


From sgehwolf at redhat.com  Tue Jul  6 14:04:28 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 06 Jul 2021 16:04:28 +0200
Subject: [8u] RFR (XS) 8265978: make test should look for more locations
 when searching for exit code
In-Reply-To: <7b3d0ab2-6cc5-4d95-d603-29e0ffd484d9@redhat.com>
References: <7b3d0ab2-6cc5-4d95-d603-29e0ffd484d9@redhat.com>
Message-ID: <db0c6995b2121ec30960b354ad3ca11732c65c5d.camel@redhat.com>

On Mon, 2021-04-26 at 18:16 +0200, Aleksey Shipilev wrote:
> 8u fix:
> ?? https://cr.openjdk.java.net/~shade/8265978/webrev.8u.01/

Yes, thanks. Looks good.

Cheers,
Severin


From shade at redhat.com  Tue Jul  6 14:10:12 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 6 Jul 2021 16:10:12 +0200
Subject: [8u] RFR (XS) 8265978: make test should look for more locations
 when searching for exit code
In-Reply-To: <db0c6995b2121ec30960b354ad3ca11732c65c5d.camel@redhat.com>
References: <7b3d0ab2-6cc5-4d95-d603-29e0ffd484d9@redhat.com>
 <db0c6995b2121ec30960b354ad3ca11732c65c5d.camel@redhat.com>
Message-ID: <1d315be1-c0bf-b95b-7283-ca1fe85c6a14@redhat.com>

On 7/6/21 4:04 PM, Severin Gehwolf wrote:
> On Mon, 2021-04-26 at 18:16 +0200, Aleksey Shipilev wrote:
>> 8u fix:
>>  ?? https://cr.openjdk.java.net/~shade/8265978/webrev.8u.01/
> 
> Yes, thanks. Looks good.

Thanks, marked for approval.

-- 
-Aleksey


From gnu.andrew at redhat.com  Tue Jul  6 16:11:26 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 6 Jul 2021 17:11:26 +0100
Subject: [8u] RFR: JDK-8220786: Create new switch to redirect error
 reporting output to stdout or stderr
In-Reply-To: <CA+3eh12ESxfkCxiON1QrGPghD1RroxUw_mkcB0OobUY1-hahBQ@mail.gmail.com>
References: <CA+3eh12ESxfkCxiON1QrGPghD1RroxUw_mkcB0OobUY1-hahBQ@mail.gmail.com>
Message-ID: <20210706161126.GA2795622@rincewind>

On 21:36 Tue 01 Jun     , Volker Simonis wrote:
> Hi,
> 
> can I please get a review for this backport?
> 
> This change initially went into jdk 13 and has already been downported
> to jdk 11u more than a year ago. But as jdk8u is still used a lot and
> increasingly in containerized environments I think it still makes a
> lot of sense to downport it to jdk 8u as well.
> 
> If the JVM crashes in a containerized environment with its ephemeral
> file system it becomes impossible to do any post mortem analysis of
> the problem. In such situations the ability to dump the hs_err file to
> stdout/stderr is very useful, because many container environments log
> the stdout/stderr stream by default.
> 
> Original issue: https://bugs.openjdk.java.net/browse/JDK-8220786
> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8220787
> Original change: http://hg.openjdk.java.net/jdk/jdk/rev/cf75ea6af695
> 
> jdk11 backport: https://bugs.openjdk.java.net/browse/JDK-8238531
> jdk11 CSR: https://bugs.openjdk.java.net/browse/JDK-8238532
> jdk11 change: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/783a56f3ac1f
> 
> jdk8 backport: https://bugs.openjdk.java.net/browse/JDK-8268055
> jdk8 CSR: https://bugs.openjdk.java.net/browse/JDK-8268058
> jdk8 webrev: http://cr.openjdk.java.net/~simonis/webrevs/2021/8220786-jdk8u/
> 
> I had to do quite some, but trivial changes to the jdk 11 backport
> (which I started with) to fit it into jdk 8u:
> 
> arguments.cpp
> -------------------
> In jdk 11 "FLAG_SET_CMDLINE(boolean, ...)" expands to "JVMFlag::Error
> boolAtPut(JVMFlagsWithType flag, bool value, JVMFlag::Flags origin)"
> which returns a "JVMFlag::Error" and can be checked for success. In
> jdk 8,  "FLAG_SET_CMDLINE(boolean, ...)" expands to "void
> boolAtPut(CommandLineFlagWithType flag, bool value, Flag::Flags
> origin)" which returns void, so there's nothing to check for...
> 
> vmError.cpp
> ----------------
> I think the initial implementation has a bug in the following code:
> 
> -    if (fd_log != -1) {
> +    if (fd_log > 3) {
>        close(fd_log);
> 
> I think the intention is to close the log stream if it was not stdout
> (i.e. "1") or stderr (i.e. "2") but it checks for "fd_log > 3".
> 
> I've fixed this in the downport but I'm happy to revert the fix if
> somebody has a good explanation for the original code:
> 
> -    if (log.fd() != defaultStream::output_fd()) {
> +    if (log.fd() > 2) {
> 
> ErrorFileRedirectTest.java
> ---------------------------------
> - path/package shuffling for the test library
> - use "Platform.isDebugBuild()" instead of "@requires (vm.debug ==
> true)" which is not supported in jdk8
> - remove "-XX:-CreateCoredumpOnCrash" option because it doesn't exist in jdk 8
> - use "-XX:ErrorHandlerTest=12" instead of "-XX:ErrorHandlerTest=14"
> because "14" is not available in jdk 8. But "12" still generates a
> SIGSEV by reading from memory address 0.
> - check for "T H R E A D" in the output because jdk 8 has no "S U M M
> A R Y" section.
> 
> The jdk 8 CSR (https://bugs.openjdk.java.net/browse/JDK-8268058) has
> been reviewed and waits for approval.
> 
> Thank you and best regards,
> Volker
> 

Thanks for the comprehensive log of the changes needed for 8u.

I assume you rolled back the local change to > 2 as Paul suggested, as I
don't see it in:

https://cr.openjdk.java.net/~simonis/webrevs/2021/8220786-jdk8u/hotspot.changeset

That seems the right thing to me. This should be handled under its own bug.

That changeset can be considered reviewed and approved.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
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

From gnu.andrew at redhat.com  Tue Jul  6 16:12:41 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 6 Jul 2021 17:12:41 +0100
Subject: [8u] RFR: 8269810: [8u] Update generated_configure.sh after
 JDK-8250876 backport
In-Reply-To: <494095e11ecca871b3cf5561eea351e153bd78d4.camel@redhat.com>
References: <494095e11ecca871b3cf5561eea351e153bd78d4.camel@redhat.com>
Message-ID: <20210706161241.GB2795622@rincewind>

On 15:07 Fri 02 Jul     , Severin Gehwolf wrote:
> Hi!
> 
> Latest jdk8u/jdk8u-dev head is out of sync as far as
> generated_configure.sh is concerned. JDK-8250876 didn't include the
> generated_configure.sh update. This patch fixes it (it's the output of
> 'bash common/autoconf/autogen.sh')
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8269810
> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8269810/01/webrev/
> 
> Thoughts?
> 
> Thanks,
> Severin
> 

I'm not sure this warranted its own bug, especially as changes in both
8u and 8u-dev will regenerate the file anyway. But thanks for sorting it.
-- 
Andrew :)
Pronouns: he / him or they / them
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

From gnu.andrew at redhat.com  Tue Jul  6 17:39:03 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 6 Jul 2021 18:39:03 +0100
Subject: [8u] RFR (S) 8079891: Store configure log in $BUILD/configure.log
In-Reply-To: <681a1ca0-1e45-e7dd-36f8-3ec395b4b97d@redhat.com>
References: <b3a2c022-97c7-1d6d-64ec-e79c8132194e@redhat.com>
 <354dc4caea576aff2d97e8d1dceedb9156e9197c.camel@redhat.com>
 <681a1ca0-1e45-e7dd-36f8-3ec395b4b97d@redhat.com>
Message-ID: <20210706173903.GA2845162@rincewind>

On 14:10 Tue 06 Jul     , Aleksey Shipilev wrote:
> On 7/2/21 5:21 PM, Severin Gehwolf wrote:
> > On Tue, 2021-04-27 at 12:01 +0200, Aleksey Shipilev wrote:
> > > Original RFE:
> > >  ?? https://bugs.openjdk.java.net/browse/JDK-8079891
> > >  ?? https://hg.openjdk.java.net/jdk9/jdk9/rev/98e85b507b09
> > > 
> > > I would like to have this simple build feature in 8u to better report configuration logs from 8u
> > > CIs. This patch applies mostly trivially, with the following changes:
> > >  ?? *) Blocks mentioning CONFIGURESUPPORT_OUTPUTDIR are removed, as these are not relevant to 8u
> > > build system;
> > >  ?? *) Minor contextual conflicts are resolved;
> > > 
> > > Current patch needs JDK-8065215 applied first to get the help block at the end of configure. This
> > > also needs JDK-8080082 as the follow-up.
> > > 
> > > Testing: 8u build; observing configure.log in build artifacts
> > 
> > Missing a link to the webrev?
> 
> Right, sorry.
> 
> Here it is (regenerated for the 8u state after JDK-8065215):
>  https://cr.openjdk.java.net/~shade/8079891/webrev.8u.02/
> 
> -- 
> Thanks,
> -Aleksey
> 

It's not clear to me what this does.

Prior to this patch, I had a config.log in my build directory.

After this patch, I have both config.log and configure.log.old, which
seems to contain largely the same information.

I don't see a configure.log.

So what exactly is the problem we're trying to solve?

I'm building as I always have for autotools projects, by invoking
configure from the build directory.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
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

From volker.simonis at gmail.com  Tue Jul  6 17:56:10 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 6 Jul 2021 19:56:10 +0200
Subject: [8u] RFR: JDK-8220786: Create new switch to redirect error
 reporting output to stdout or stderr
In-Reply-To: <20210706161126.GA2795622@rincewind>
References: <CA+3eh12ESxfkCxiON1QrGPghD1RroxUw_mkcB0OobUY1-hahBQ@mail.gmail.com>
 <20210706161126.GA2795622@rincewind>
Message-ID: <CA+3eh11XW9MVqN-PPSsvn2D4yG_TFGAPsTSFAzSQ5MvbtS5sbQ@mail.gmail.com>

Yes, you're right. I've reverted the extra fix in place as Paul suggested.

Thanks a lot for reviewing,
Volker

On Tue, Jul 6, 2021 at 6:11 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
> On 21:36 Tue 01 Jun     , Volker Simonis wrote:
> > Hi,
> >
> > can I please get a review for this backport?
> >
> > This change initially went into jdk 13 and has already been downported
> > to jdk 11u more than a year ago. But as jdk8u is still used a lot and
> > increasingly in containerized environments I think it still makes a
> > lot of sense to downport it to jdk 8u as well.
> >
> > If the JVM crashes in a containerized environment with its ephemeral
> > file system it becomes impossible to do any post mortem analysis of
> > the problem. In such situations the ability to dump the hs_err file to
> > stdout/stderr is very useful, because many container environments log
> > the stdout/stderr stream by default.
> >
> > Original issue: https://bugs.openjdk.java.net/browse/JDK-8220786
> > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8220787
> > Original change: http://hg.openjdk.java.net/jdk/jdk/rev/cf75ea6af695
> >
> > jdk11 backport: https://bugs.openjdk.java.net/browse/JDK-8238531
> > jdk11 CSR: https://bugs.openjdk.java.net/browse/JDK-8238532
> > jdk11 change: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/783a56f3ac1f
> >
> > jdk8 backport: https://bugs.openjdk.java.net/browse/JDK-8268055
> > jdk8 CSR: https://bugs.openjdk.java.net/browse/JDK-8268058
> > jdk8 webrev: http://cr.openjdk.java.net/~simonis/webrevs/2021/8220786-jdk8u/
> >
> > I had to do quite some, but trivial changes to the jdk 11 backport
> > (which I started with) to fit it into jdk 8u:
> >
> > arguments.cpp
> > -------------------
> > In jdk 11 "FLAG_SET_CMDLINE(boolean, ...)" expands to "JVMFlag::Error
> > boolAtPut(JVMFlagsWithType flag, bool value, JVMFlag::Flags origin)"
> > which returns a "JVMFlag::Error" and can be checked for success. In
> > jdk 8,  "FLAG_SET_CMDLINE(boolean, ...)" expands to "void
> > boolAtPut(CommandLineFlagWithType flag, bool value, Flag::Flags
> > origin)" which returns void, so there's nothing to check for...
> >
> > vmError.cpp
> > ----------------
> > I think the initial implementation has a bug in the following code:
> >
> > -    if (fd_log != -1) {
> > +    if (fd_log > 3) {
> >        close(fd_log);
> >
> > I think the intention is to close the log stream if it was not stdout
> > (i.e. "1") or stderr (i.e. "2") but it checks for "fd_log > 3".
> >
> > I've fixed this in the downport but I'm happy to revert the fix if
> > somebody has a good explanation for the original code:
> >
> > -    if (log.fd() != defaultStream::output_fd()) {
> > +    if (log.fd() > 2) {
> >
> > ErrorFileRedirectTest.java
> > ---------------------------------
> > - path/package shuffling for the test library
> > - use "Platform.isDebugBuild()" instead of "@requires (vm.debug ==
> > true)" which is not supported in jdk8
> > - remove "-XX:-CreateCoredumpOnCrash" option because it doesn't exist in jdk 8
> > - use "-XX:ErrorHandlerTest=12" instead of "-XX:ErrorHandlerTest=14"
> > because "14" is not available in jdk 8. But "12" still generates a
> > SIGSEV by reading from memory address 0.
> > - check for "T H R E A D" in the output because jdk 8 has no "S U M M
> > A R Y" section.
> >
> > The jdk 8 CSR (https://bugs.openjdk.java.net/browse/JDK-8268058) has
> > been reviewed and waits for approval.
> >
> > Thank you and best regards,
> > Volker
> >
>
> Thanks for the comprehensive log of the changes needed for 8u.
>
> I assume you rolled back the local change to > 2 as Paul suggested, as I
> don't see it in:
>
> https://cr.openjdk.java.net/~simonis/webrevs/2021/8220786-jdk8u/hotspot.changeset
>
> That seems the right thing to me. This should be handled under its own bug.
>
> That changeset can be considered reviewed and approved.
>
> Thanks,
> --
> Andrew :)
> Pronouns: he / him or they / them
> 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

From shade at redhat.com  Tue Jul  6 18:21:11 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 6 Jul 2021 20:21:11 +0200
Subject: [8u] RFR (S) 8079891: Store configure log in $BUILD/configure.log
In-Reply-To: <20210706173903.GA2845162@rincewind>
References: <b3a2c022-97c7-1d6d-64ec-e79c8132194e@redhat.com>
 <354dc4caea576aff2d97e8d1dceedb9156e9197c.camel@redhat.com>
 <681a1ca0-1e45-e7dd-36f8-3ec395b4b97d@redhat.com>
 <20210706173903.GA2845162@rincewind>
Message-ID: <f3f52f15-9405-6a44-e038-45b3f7cbce00@redhat.com>

On 7/6/21 7:39 PM, Andrew Hughes wrote:
> It's not clear to me what this does.
> 
> Prior to this patch, I had a config.log in my build directory.

Yes, in the `pwd`:

jdk8u-dev $ find | grep config.log
./config.log

That one contains the messages that compilers produce when running ./configure.

> After this patch, I have both config.log and configure.log.old, which
> seems to contain largely the same information.
> 
> I don't see a configure.log.

It should be in per-config dir, and it contains the ./configure log, the same that you normally see 
in console, including configure warnings, etc.

jdk8u-dev $ find | grep configure.log
./build/linux-x86_64-normal-server-fastdebug/configure.log

It is symmetrical to the already existing build.log that captures the build output that you normally 
see in console as well.

jdk8u-dev $ find | grep build.log
./build/linux-x86_64-normal-server-fastdebug/build.log

> So what exactly is the problem we're trying to solve?

Exactly those logs are useful to see what is being built. Capturing them is a hassle, though.

Capturing ./configure output from stdout is doable, until you get into exit code handling, which is 
quite a mess (i.e. capturing the error code from the piped commands is sane mostly when forcing 
bash-isms like "set -o pipefail"). Configure output saved as file is significantly easier to deal with.

This backport helps at least my CIs to capture configure logs for jdk8u, as it is done for every 
other release already:
   https://builds.shipilev.net/openjdk-jdk8-dev/configure-logs/
   https://builds.shipilev.net/openjdk-jdk/configure-logs/

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Jul  6 18:36:44 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 6 Jul 2021 20:36:44 +0200
Subject: [8u] RFR (S) 8079891: Store configure log in $BUILD/configure.log
In-Reply-To: <f3f52f15-9405-6a44-e038-45b3f7cbce00@redhat.com>
References: <b3a2c022-97c7-1d6d-64ec-e79c8132194e@redhat.com>
 <354dc4caea576aff2d97e8d1dceedb9156e9197c.camel@redhat.com>
 <681a1ca0-1e45-e7dd-36f8-3ec395b4b97d@redhat.com>
 <20210706173903.GA2845162@rincewind>
 <f3f52f15-9405-6a44-e038-45b3f7cbce00@redhat.com>
Message-ID: <97ced113-8246-bb27-2c99-50b389ef388b@redhat.com>

On 7/6/21 8:21 PM, Aleksey Shipilev wrote:
> On 7/6/21 7:39 PM, Andrew Hughes wrote:
>> It's not clear to me what this does.
>>
>> Prior to this patch, I had a config.log in my build directory.
> 
> Yes, in the `pwd`:
> 
> jdk8u-dev $ find | grep config.log
> ./config.log

Gaaa, I think I dropped one of the blocks accidentally. config.log should also reside in the config 
directory, along with configure.log.

I'll rectify this with a follow-up bug:
   https://bugs.openjdk.java.net/browse/JDK-8269953

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Jul  6 18:42:36 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 6 Jul 2021 20:42:36 +0200
Subject: [8u] RFR (XS) 8269953: config.log is not in build directory after 8u
 backport of JDK-8079891
Message-ID: <4f39fde6-1984-746a-f3ed-08916a4968e2@redhat.com>

Apologies, I just introduced a minor 8u-specific build infra bug:
   https://bugs.openjdk.java.net/browse/JDK-8269953

Configure current jdk8u-dev and see:

jdk8u-dev $ find | grep config.log
config.log

...while it should be here:

jdk8u-dev $ find | grep config.log
./build/linux-x86_64-normal-server-fastdebug/config.log

This block was accidentally dropped:
   http://hg.openjdk.java.net/jdk8u/jdk8u-dev/rev/7cf12efdd88d#l3.11

8u webrev:
  http://cr.openjdk.java.net/~shade/8269953/webrev.8u.01/

Testing: observing where is config.log

-- 
Thanks,
-Aleksey


From felix.yang at huawei.com  Wed Jul  7 08:19:56 2021
From: felix.yang at huawei.com (Yangfei (Felix))
Date: Wed, 7 Jul 2021 08:19:56 +0000
Subject: PING: RE: RFR: 8233019: java.lang.Class.isPrimitive() (C1)
 returns wrong result if Klass* is aligned to 32bit
Message-ID: <a9c6ae117c1542ae864444994bb7047c@huawei.com>

Hi,

Let me revive this.

Any comments please?

I have also prepared a 8u backport of 8150669:
    http://cr.openjdk.java.net/~fyang/8150669-8u/webrev.00/

Thanks,
Felix

> 
> Hi Andrew,
> 
> Thanks for the reply :-)
> 
> > -----Original Message-----
> > From: Andrew Hughes [mailto:gnu.andrew at redhat.com]
> > Sent: Tuesday, May 18, 2021 10:07 AM
> > To: Yangfei (Felix) <felix.yang at huawei.com>
> > Cc: Aleksey Shipilev <shade at redhat.com>; jdk8u-dev <jdk8u-
> > dev at openjdk.java.net>
> > Subject: Re: PING: RE: RFR: 8233019: java.lang.Class.isPrimitive()
> > (C1) returns wrong result if Klass* is aligned to 32bit
> >
> > On 01:15 Tue 18 May     , Yangfei (Felix) wrote:
> > > Gentle ping ...
> > >
> > > Any comments from our maintainers?
> > >
> > > Thanks,
> > > Felix
> > >
> > > > -----Original Message-----
> > > > From: Yangfei (Felix)
> > > > Sent: Tuesday, April 27, 2021 8:18 PM
> > > > To: 'Aleksey Shipilev' <shade at redhat.com>; jdk8u-dev <jdk8u-
> > > > dev at openjdk.java.net>
> > > > Subject: RE: RFR: 8233019: java.lang.Class.isPrimitive() (C1)
> > > > returns wrong result if Klass* is aligned to 32bit
> > > >
> > > > Hi,
> > > >
> > > > Thanks for the quick reply :-)
> > > >
> > > > > -----Original Message-----
> > > > > From: Aleksey Shipilev [mailto:shade at redhat.com]
> > > > > Sent: Monday, April 26, 2021 9:00 PM
> > > > > To: Yangfei (Felix) <felix.yang at huawei.com>; jdk8u-dev <jdk8u-
> > > > > dev at openjdk.java.net>
> > > > > Subject: Re: RFR: 8233019: java.lang.Class.isPrimitive() (C1)
> > > > > returns wrong result if Klass* is aligned to 32bit
> > > > >
> > > > > On 4/26/21 2:52 PM, Yangfei (Felix) wrote:
> > > > > > I find issue JDK-8239477 [1] is triggering for 16 jfr jtreg
> > > > > > tests with fastdebug
> > > > > build.
> > > > > > Fix for this issue depends on JDK-8233019 as it emits a
> > > > > > compare with
> > > > > metadataConst(0).
> > > > > > So need to backport JDK-8233019 first.
> > > > > >
> > > > > > Original bug:
> > > > > >      https://bugs.openjdk.java.net/browse/JDK-8233019
> > > > > >
> > > > > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/e1b6631cbd2
> > > > > > f
> > > > > >
> > > > > > Original patch does not apply to 8u cleanly. Two adaptations
> > > > > > are made for
> > > > > 8u:
> > > > > > 1. Discarded changes in file c1_LIRGenerator.cpp as
> > > > > > JDK-8150669 [2] is not
> > > > > there in 8u.
> > > > > > 2. Added new test
> > > > > hotspot/test/compiler/intrinsics/class/TestClassIsPrimitive.java
> > > > > which was introduced by [2] and further modified by this issue.
> > > > >
> > > > > Honestly, I would consider backporting JDK-8150669 first. It
> > > > > seems quite
> > > > small:
> > > > >
> > > > > https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d15b795cdf21
> > > > >
> > > > > Otherwise, we are splicing the fix under the unrelated synopsis...
> > > > >
> > > > > Let 8u maintainers decide.
> > > >
> > > > Yes, I agree it will be more cleaner if we backport JDK-8150669 first.
> > > > And I am happy to propose another 8u webrev for JDK-8150669 if
> > > > it's OK for 8u maintainers.
> > > >
> > > > Felix
> >
> > Sorry, only just seen this.
> >
> > My understanding of these bugs is as follows:
> >
> > 1. JDK-8150669: "C1 intrinsic for Class.isPrimitive" is an enhancement
> > which improves the performance of Class.isPrimitive
> >
> > 2. JDK-8233019: "java.lang.Class.isPrimitive() (C1) returns wrong
> > result if
> > Klass* is aligned to 32bit" fixes a bug in #1.
> > In the process, it introduces handling of T_METADATA in C1.
> >
> > 3. JDK-8239477: "jdk/jfr/jcmd/TestJcmdStartStopDefault.java fails -
> > XX:+VerifyOops with "verify_oop: rsi: broken oop" is, AFAICS,
> > completely unrelated to Class.isPrimitive, but the fix relies on the
> > T_METADATA change that was bundled with #2.
> 
> Yes, that's correct.
> 
> > I'm confused as to why your original backport [0] added a test for the
> > Class.isPrimitive intrinsic, when the intrinsic is not been
> > backported. That makes no sense to me.
> 
> That's because [0] backports JDK-8233019 and JDK-8233019 adds extra
> checks to the test.
> So I simply added the whole test case for backport [0] for test coverage.
> 
> > I think you can go in one of two directions here; either backport all
> > three pretty much as is, or just backport JDK-8239477, and include the
> > T_METADATA additions. The latter is no different to what was done in
> > #2, bundling the additions in with the fix that needed to use them.
> 
> Personally, I would like to backport all three so that the three backports will
> be cleaner.
> But let's see what Aleksey would say about the risk of this way.
> 
> > My initial feeling is just to backport JDK-8239477 with the necessary
> > extra code. Adding an performance enhancement just so you can backport
> > a fix for said enhancement which brings in some other unrelated code
> > seems to be introducing unnecessary risk here.
> >
> > However, it seems Aleksey is the original author of JDK-8150669, so
> > I'd appreciate his input on how risky/worthwhile he feels it is to
> > backport.  If
> > JDK-8150669 has merit to being backported in isolation, then we can go
> > with all three.  Otherwise, I would just extend a
> > JDK-8239477 backport with the additional T_METADATA code it requires,
> > as
> > JDK-8150669 shouldn't be backported just for the sake of 8239477.
> >
> > [0] https://cr.openjdk.java.net/~fyang/8233019-
> > 8u/webrev.00/hotspot.changeset
> > --
> > 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

From mails.mail.openjdk.java.net at gunter.ohrner.net  Wed Jul  7 08:33:26 2021
From: mails.mail.openjdk.java.net at gunter.ohrner.net (Gunter Ohrner)
Date: Wed, 7 Jul 2021 10:33:26 +0200
Subject: =?UTF-8?Q?Re=3A_=5B8u=5D_RFR_=28S=29_8194246=3A_JVM_crashes_when_cal?=
 =?UTF-8?Q?ling_getStackTrace_ifstackcontains_a_method_that_is_a_memb?=
 =?UTF-8?Q?er_of_a_very_large_class?=
In-Reply-To: <e52d0aef-c2b4-22df-fd90-2ef55cb53dda@redhat.com>
References: <e52d0aef-c2b4-22df-fd90-2ef55cb53dda@redhat.com>
Message-ID: <f0595e3c-0973-4041-42e6-91ef2e305fcc@ohrner.net>

Am 05.07.21 um 10:35 schrieb Aleksey Shipilev:
> Original bug:
> ? https://bugs.openjdk.java.net/browse/JDK-8194246
(...)
> 8u webrev:
> ? https://cr.openjdk.java.net/~shade/8194246/webrev.8u.01/

Thanks, I created a custom OpenJDK 8 Debian package which includes this 
patch, and it seems to solve our issues - the crash is gone now.

Thanks and regards,

 ? Gunter


From sgehwolf at redhat.com  Wed Jul  7 09:11:39 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 07 Jul 2021 11:11:39 +0200
Subject: [8u] RFR (XS) 8269953: config.log is not in build directory
 after 8u backport of JDK-8079891
In-Reply-To: <4f39fde6-1984-746a-f3ed-08916a4968e2@redhat.com>
References: <4f39fde6-1984-746a-f3ed-08916a4968e2@redhat.com>
Message-ID: <e4cf1d7bd91383e6e682bc13594071471488ec48.camel@redhat.com>

On Tue, 2021-07-06 at 20:42 +0200, Aleksey Shipilev wrote:
> Apologies, I just introduced a minor 8u-specific build infra bug:
> ?? https://bugs.openjdk.java.net/browse/JDK-8269953
> 
> Configure current jdk8u-dev and see:
> 
> jdk8u-dev $ find | grep config.log
> config.log
> 
> ...while it should be here:
> 
> jdk8u-dev $ find | grep config.log
> ./build/linux-x86_64-normal-server-fastdebug/config.log
> 
> This block was accidentally dropped:
> ?? http://hg.openjdk.java.net/jdk8u/jdk8u-dev/rev/7cf12efdd88d#l3.11
> 
> 8u webrev:
> ? http://cr.openjdk.java.net/~shade/8269953/webrev.8u.01/
> 
> Testing: observing where is config.log

Looks OK to me.

Thanks,
Severin


From shade at redhat.com  Wed Jul  7 09:16:43 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 7 Jul 2021 11:16:43 +0200
Subject: [8u] RFR (XS) 8269953: config.log is not in build directory after
 8u backport of JDK-8079891
In-Reply-To: <e4cf1d7bd91383e6e682bc13594071471488ec48.camel@redhat.com>
References: <4f39fde6-1984-746a-f3ed-08916a4968e2@redhat.com>
 <e4cf1d7bd91383e6e682bc13594071471488ec48.camel@redhat.com>
Message-ID: <4cffba05-bc54-13eb-92b3-f8bdef9050db@redhat.com>

On 7/7/21 11:11 AM, Severin Gehwolf wrote:
> Looks OK to me.

Thanks, tagged.

-- 
-Aleksey


From gnu.andrew at redhat.com  Wed Jul  7 17:08:44 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 7 Jul 2021 18:08:44 +0100
Subject: [8u] RFR (S) 8079891: Store configure log in $BUILD/configure.log
In-Reply-To: <f3f52f15-9405-6a44-e038-45b3f7cbce00@redhat.com>
References: <b3a2c022-97c7-1d6d-64ec-e79c8132194e@redhat.com>
 <354dc4caea576aff2d97e8d1dceedb9156e9197c.camel@redhat.com>
 <681a1ca0-1e45-e7dd-36f8-3ec395b4b97d@redhat.com>
 <20210706173903.GA2845162@rincewind>
 <f3f52f15-9405-6a44-e038-45b3f7cbce00@redhat.com>
Message-ID: <20210707170844.GB2994035@rincewind>

On 20:21 Tue 06 Jul     , Aleksey Shipilev wrote:
> On 7/6/21 7:39 PM, Andrew Hughes wrote:
> > It's not clear to me what this does.
> > 
> > Prior to this patch, I had a config.log in my build directory.
> 
> Yes, in the `pwd`:
> 
> jdk8u-dev $ find | grep config.log
> ./config.log
>

Ah, yes, my `pwd` would be the build directory :-)

Moving this seems incomplete because there are other files output by
configure, like config.status.  The real solution is for builddir != srcdir
(a "VPATH build")

OpenJDK only uses autoconf and not automake, so the use of 'make
distcheck' is also not routine. We used to use that on GNU Classpath
before release, to ensure that the build could complete from the
distribution tarball, using a separate build tree, with the source
directory read only [0].

> That one contains the messages that compilers produce when running ./configure.
> 
> > After this patch, I have both config.log and configure.log.old, which
> > seems to contain largely the same information.
> > 
> > I don't see a configure.log.
> 
> It should be in per-config dir, and it contains the ./configure log, the
> same that you normally see in console, including configure warnings, etc.
> 
> jdk8u-dev $ find | grep configure.log
> ./build/linux-x86_64-normal-server-fastdebug/configure.log
>

No joy before or after the patch:

$ find ~/builder/8u-dev.old -name 'configure.log'
$ find ~/builder/8u-dev -name 'configure.log'

> It is symmetrical to the already existing build.log that captures the build
> output that you normally see in console as well.
> 
> jdk8u-dev $ find | grep build.log
> ./build/linux-x86_64-normal-server-fastdebug/build.log
>

Those I do have :/

$ find ~/builder/8u-dev.old -name 'build.log'
/home/ahughes/builder/8u-dev.old/build.log
$ find ~/builder/8u-dev -name 'build.log'
/home/ahughes/builder/8u-dev/build.log

configure.log is not in the source tree either. I'll have to dig through
what is going on when I get time.

> > So what exactly is the problem we're trying to solve?
> 
> Exactly those logs are useful to see what is being built. Capturing them is a hassle, though.
> 
> Capturing ./configure output from stdout is doable, until you get into exit
> code handling, which is quite a mess (i.e. capturing the error code from the
> piped commands is sane mostly when forcing bash-isms like "set -o
> pipefail"). Configure output saved as file is significantly easier to deal
> with.
> 
> This backport helps at least my CIs to capture configure logs for jdk8u, as
> it is done for every other release already:
>   https://builds.shipilev.net/openjdk-jdk8-dev/configure-logs/
>   https://builds.shipilev.net/openjdk-jdk/configure-logs/
>

I get that. I've just never had recourse to use anything but config.log. It
actually provides more detailed output with the variable settings and test
failures (essential when debugging a new configure test)

The main addition in configure.log seems to be the JDK's only pre- and
post- configure output. Off-hand, it seems that this is actually a bug
that this isn't logged to config.log (AS_MESSAGE_LOG_FD) [1] [2].
Again, I'll have a look at how this behaves on trunk after the CPU.

> -- 
> Thanks,
> -Aleksey
> 

[0] https://www.gnu.org/software/automake/manual/html_node/Checking-the-Distribution.html
[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/File-Descriptor-Macros.html#AS%5fMESSAGE%5fLOG%5fFD
[2] https://icedtea.wildebeest.org/hg/icedtea8/file/tip/acinclude.m4#l468
-- 
Andrew :)
Pronouns: he / him or they / them
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

From gnu.andrew at redhat.com  Wed Jul  7 17:13:52 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 7 Jul 2021 18:13:52 +0100
Subject: [8u] RFR (XS) 8269953: config.log is not in build directory
 after 8u backport of JDK-8079891
In-Reply-To: <e4cf1d7bd91383e6e682bc13594071471488ec48.camel@redhat.com>
References: <4f39fde6-1984-746a-f3ed-08916a4968e2@redhat.com>
 <e4cf1d7bd91383e6e682bc13594071471488ec48.camel@redhat.com>
Message-ID: <20210707171352.GC2994035@rincewind>

On 11:11 Wed 07 Jul     , Severin Gehwolf wrote:
> On Tue, 2021-07-06 at 20:42 +0200, Aleksey Shipilev wrote:
> > Apologies, I just introduced a minor 8u-specific build infra bug:
> > ?? https://bugs.openjdk.java.net/browse/JDK-8269953
> > 
> > Configure current jdk8u-dev and see:
> > 
> > jdk8u-dev $ find | grep config.log
> > config.log
> > 
> > ...while it should be here:
> > 
> > jdk8u-dev $ find | grep config.log
> > ./build/linux-x86_64-normal-server-fastdebug/config.log
> > 
> > This block was accidentally dropped:
> > ?? http://hg.openjdk.java.net/jdk8u/jdk8u-dev/rev/7cf12efdd88d#l3.11
> > 
> > 8u webrev:
> > ? http://cr.openjdk.java.net/~shade/8269953/webrev.8u.01/
> > 
> > Testing: observing where is config.log
> 
> Looks OK to me.
> 
> Thanks,
> Severin
> 

Happy for this to go in as well. I presume in my case, where $(pwd) =
OUTPUT_ROOT, it will fail, trying to copy the file over itself?

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
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

From shade at redhat.com  Wed Jul  7 17:17:50 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 7 Jul 2021 19:17:50 +0200
Subject: [8u] RFR (XS) 8269953: config.log is not in build directory after
 8u backport of JDK-8079891
In-Reply-To: <20210707171352.GC2994035@rincewind>
References: <4f39fde6-1984-746a-f3ed-08916a4968e2@redhat.com>
 <e4cf1d7bd91383e6e682bc13594071471488ec48.camel@redhat.com>
 <20210707171352.GC2994035@rincewind>
Message-ID: <6e2d8b3c-2953-57e4-d855-8b740d60d022@redhat.com>

On 7/7/21 7:13 PM, Andrew Hughes wrote:
> Happy for this to go in as well. I presume in my case, where $(pwd) =
> OUTPUT_ROOT, it will fail, trying to copy the file over itself?

Thanks! Got the approval, pushed.

I think "mv" error would be ignored in this case? Given it is the same code that was used 
originally, this would not regress anything, so we could see what is going on at your system a bit 
later.


-- 
-Aleksey


From gnu.andrew at redhat.com  Wed Jul  7 17:47:12 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 7 Jul 2021 18:47:12 +0100
Subject: [8u] RFR (XS) 8269953: config.log is not in build directory
 after 8u backport of JDK-8079891
In-Reply-To: <6e2d8b3c-2953-57e4-d855-8b740d60d022@redhat.com>
References: <4f39fde6-1984-746a-f3ed-08916a4968e2@redhat.com>
 <e4cf1d7bd91383e6e682bc13594071471488ec48.camel@redhat.com>
 <20210707171352.GC2994035@rincewind>
 <6e2d8b3c-2953-57e4-d855-8b740d60d022@redhat.com>
Message-ID: <20210707174712.GD2994035@rincewind>

On 19:17 Wed 07 Jul     , Aleksey Shipilev wrote:
> On 7/7/21 7:13 PM, Andrew Hughes wrote:
> > Happy for this to go in as well. I presume in my case, where $(pwd) =
> > OUTPUT_ROOT, it will fail, trying to copy the file over itself?
> 
> Thanks! Got the approval, pushed.
> 
> I think "mv" error would be ignored in this case? Given it is the same code
> that was used originally, this would not regress anything, so we could see
> what is going on at your system a bit later.
> 
> 
> -- 
> -Aleksey
> 

Yeah, it looks like it'll just be silenced to /dev/null.  I need to dig in
from trunk downwards after the CPU.

Thanks for making me aware of this.
-- 
Andrew :)
Pronouns: he / him or they / them
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

From shade at redhat.com  Fri Jul  9 08:00:44 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 9 Jul 2021 10:00:44 +0200
Subject: [8u] RFR (S) 8194246: JVM crashes when calling getStackTrace
 ifstackcontains a method that is a member of a very large class
In-Reply-To: <f0595e3c-0973-4041-42e6-91ef2e305fcc@ohrner.net>
References: <e52d0aef-c2b4-22df-fd90-2ef55cb53dda@redhat.com>
 <f0595e3c-0973-4041-42e6-91ef2e305fcc@ohrner.net>
Message-ID: <35d3e3f6-8476-fdf3-af45-96d75ed8a90d@redhat.com>

On 7/7/21 10:33 AM, Gunter Ohrner wrote:
> Am 05.07.21 um 10:35 schrieb Aleksey Shipilev:
>> Original bug:
>>  ? https://bugs.openjdk.java.net/browse/JDK-8194246
> (...)
>> 8u webrev:
>>  ? https://cr.openjdk.java.net/~shade/8194246/webrev.8u.01/
> 
> Thanks, I created a custom OpenJDK 8 Debian package which includes this
> patch, and it seems to solve our issues - the crash is gone now.

Thanks, that is good to know.

-- 
-Aleksey


From akashche at redhat.com  Mon Jul 12 12:14:57 2021
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 12 Jul 2021 13:14:57 +0100
Subject: [8u] RFR: 8177536: Avoid Apple Peer-to-Peer interfaces in networking
 tests
Message-ID: <CABUxsJ07q4LE-pXQMtc0F2AT2zp=XTx3wf-HMNA3UQBhHQ8L1Q@mail.gmail.com>

Hi,

Please review the backport of JDK-8177536 to 8u:

Bug: https://bugs.openjdk.java.net/browse/JDK-8177536

Original commit: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/389b078873a0

8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8177536/webrev.00/

Patch applies to 8u almost cleanly, only the changes to
test/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java are
omitted (because this test has different history in 8u and
corresponding change is already there). Testing: checked that changed
tests pass cleanly on macOS.


[1] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/log/6ad1494ea3f4/test/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java

-- 
-Alex


From wessel.van.norel at delgurth.com  Mon Jul 12 23:43:37 2021
From: wessel.van.norel at delgurth.com (Wessel van Norel)
Date: Tue, 13 Jul 2021 01:43:37 +0200
Subject: JDK8: Compile error introduced with backport JDK-8258780 for
 https://bugs.openjdk.java.net/browse/JDK-8078024
Message-ID: <B4E164DF-D0F7-4A03-BCDA-D2609A7964B9@delgurth.com>

L.S.

Something is bugging me for some time already and I think I?ve found enough information to proceed, at least assuming that I?ve found the correct place to send this e-mail to and ask a question.

https://bugs.openjdk.java.net/browse/JDK-8078024 has been backported with https://bugs.openjdk.java.net/browse/JDK-8258780. The statement in the release notes says:


This fix has source compatibility impact, right now code that wasn't being accepted is now being accepted by the javac compiler. Currently there are no reports of any other kind of incompatibility.


This might be true on java 9+, but unfortunately on java 8 it has introduced a false negative. At least, the test case I?ve ?compiled" compiles on java 9 - 16, and on java 8u282, but not on java 8u292.


I?ve tried to bring the test-case back to a minimum. See attached file. 

Without a ?List" the code also fails to compile on java 8u282 (so before the backport of JDK-8258780).

And if I remove the ".map(ref -> (BugTrigger<? extends SuperOrExtends>) ref)"

modern (9+) compilers also do not accept the code: "reason: no instance(s) of type variable(s) exist so that capture of ? extends SuperOrExtends conforms to capture of ? extends SuperOrExtends?

Which is technically not true, if I understood the "? extends" vs the "? super" correctly. In case you have an object of type SuperOrExtends both "? super SuperOrExtends? and ?? extends SuperOrExtends? are valid for the object. You should not want this, because why would you work with generics if all you provide is the exact type, but that?s a different story.



The java 8 u 292 compile error on this code is (with ?proof? that it works on other versions):

$ javac -version && javac SuperOrExtends.java
javac 16.0.1
$ javac -version && javac SuperOrExtends.java
javac 9.0.7.1
$ javac -version && javac SuperOrExtends.java
javac 1.8.0_282
$ javac -version && javac SuperOrExtends.java
javac 1.8.0_292
SuperOrExtends.java:11: error: method updateValues in class SuperOrExtends cannot be applied to given types;
                .forEach(ref -> updateValues(param1.trigger(ref), Collections.singletonList(ref)));
                                ^
  required: BugTrigger<A>,List<BugTrigger<? super A>>
  found: BugTrigger<CAP#1>,List<BugTrigger<CAP#1>>
  reason: inference variable T has incompatible bounds
    equality constraints: BugTrigger<? super A>
    lower bounds: BugTrigger<CAP#1>
  where A,T are type-variables:
    A extends SuperOrExtends declared in method <A>updateValues(BugTrigger<A>,List<BugTrigger<? super A>>)
    T extends Object declared in method <T>singletonList(T)
  where CAP#1 is a fresh type-variable:
    CAP#1 extends SuperOrExtends from capture of ? extends SuperOrExtends
1 error

Seeing this error the problem lies in:

https://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/rev/cd6eb36db1bb#l1.32


Unfortunately fixing it will most likely not be trivial, seeing that the problem resides in code that was not introduced in this patch, and seeing that changing the code a bit can also cause modern and older compilers to fail. But before I investigate further how to fix this I want to ask a question:

What steps, besides the code fix, would I need to take to get a possible fix into jdk8u-dev? Since this is not a bug in any of the upstream versions, only in this version I thought this mailing-list would be the appropriate channel to provide a fix.


I thank you for your time.

Kind regards,
Wessel van Norel

From wessel.van.norel at delgurth.com  Tue Jul 13 00:02:31 2021
From: wessel.van.norel at delgurth.com (Wessel van Norel)
Date: Tue, 13 Jul 2021 02:02:31 +0200
Subject: JDK8: Compile error introduced with backport JDK-8258780 for
 https://bugs.openjdk.java.net/browse/JDK-8078024
In-Reply-To: <B4E164DF-D0F7-4A03-BCDA-D2609A7964B9@delgurth.com>
References: <B4E164DF-D0F7-4A03-BCDA-D2609A7964B9@delgurth.com>
Message-ID: <6CB55570-EAD2-4530-94EF-DFEDD6D14B79@delgurth.com>


> On 13 Jul 2021, at 01:43, Wessel van Norel <wessel.van.norel at delgurth.com> wrote:

<snip>

> I?ve tried to bring the test-case back to a minimum. See attached file. 

Attachment seems to have gone missing. Created a gist: https://gist.github.com/delgurth/9557f821d256070de4cc9e28cbeb0f82

Kind regards,
Wessel van Norel


From sgehwolf at redhat.com  Tue Jul 13 16:28:12 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 13 Jul 2021 18:28:12 +0200
Subject: [8u] RFR: 8247469: getSystemCpuLoad() returns -1 on linux when some
 offline cpus are present and cpusets.effective_cpus is not available
Message-ID: <4c7059356047f06a6f9dbcefaaeace16fd6617d3.camel@redhat.com>

Hi,

This is a prerequisite backport for JDK-8265836, which I'd like to
bring to OpenJDK 8u as the bug is present there too[2]. Note that the
OperatingSystemMXBean has been made container aware with JDK-8226575[1]
in 8u272 and better.

The OpenJDK 11u patch doesn't apply cleanly due to restructuring of the
code in later JDKs. The gist of the patch is still the same. One
addition of note is the mapfile-vers change for the new native method.

Bug: https://bugs.openjdk.java.net/browse/JDK-8247469
webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8247469/jdk8/02/webrev/

Testing: Builds on Linux x86_64, Solaris Sparc, AIX.
         Manually via the reproducer for JDK-8265836. Tier 1 on Linux x86_64

Thoughts?

Thanks,
Severin

[1] https://bugs.openjdk.java.net/browse/JDK-8226575
[2] https://bugs.openjdk.java.net/browse/JDK-8269874?focusedCommentId=14432127&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14432127


From adinn at redhat.com  Tue Jul 13 16:41:19 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 13 Jul 2021 17:41:19 +0100
Subject: [8u] RFR: 8247469: getSystemCpuLoad() returns -1 on linux when
 some offline cpus are present and cpusets.effective_cpus is not available
In-Reply-To: <4c7059356047f06a6f9dbcefaaeace16fd6617d3.camel@redhat.com>
References: <4c7059356047f06a6f9dbcefaaeace16fd6617d3.camel@redhat.com>
Message-ID: <5f020893-408d-5ee8-7ebe-8d0ef807a866@redhat.com>

On 13/07/2021 17:28, Severin Gehwolf wrote:
> This is a prerequisite backport for JDK-8265836, which I'd like to
> bring to OpenJDK 8u as the bug is present there too[2]. Note that the
> OperatingSystemMXBean has been made container aware with JDK-8226575[1]
> in 8u272 and better.
> 
> The OpenJDK 11u patch doesn't apply cleanly due to restructuring of the
> code in later JDKs. The gist of the patch is still the same. One
> addition of note is the mapfile-vers change for the new native method.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8247469
> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8247469/jdk8/02/webrev/
> 
> Testing: Builds on Linux x86_64, Solaris Sparc, AIX.
>           Manually via the reproducer for JDK-8265836. Tier 1 on Linux x86_64
> 
> Thoughts?
The backport looks good to me and it certainly looks necessary as a 
prerequisite for backport for JDK-8265836. So count this as a review.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From peter.zhelezniakov at bell-sw.com  Tue Jul 13 16:47:01 2021
From: peter.zhelezniakov at bell-sw.com (Peter Zhelezniakov)
Date: Tue, 13 Jul 2021 19:47:01 +0300
Subject: JDK8: Compile error introduced with backport JDK-8258780
 for https://bugs.openjdk.java.net/browse/JDK-8078024
In-Reply-To: <6CB55570-EAD2-4530-94EF-DFEDD6D14B79@delgurth.com>
References: <6CB55570-EAD2-4530-94EF-DFEDD6D14B79@delgurth.com>
Message-ID: <62B89706-0804-44AD-AC7D-4627C679015D@getmailspring.com>

Hi Wessel,
I will look into this. I'm going to try to identify other fixes that might have played a role here.

Thanks!

From sgehwolf at redhat.com  Tue Jul 13 16:56:38 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 13 Jul 2021 18:56:38 +0200
Subject: [8u] RFR: 8247469: getSystemCpuLoad() returns -1 on linux when
 some offline cpus are present and cpusets.effective_cpus is not available
In-Reply-To: <5f020893-408d-5ee8-7ebe-8d0ef807a866@redhat.com>
References: <4c7059356047f06a6f9dbcefaaeace16fd6617d3.camel@redhat.com>
 <5f020893-408d-5ee8-7ebe-8d0ef807a866@redhat.com>
Message-ID: <d1f30d31808571a1480a1b5220420cb4a75380cb.camel@redhat.com>

On Tue, 2021-07-13 at 17:41 +0100, Andrew Dinn wrote:
> On 13/07/2021 17:28, Severin Gehwolf wrote:
> > This is a prerequisite backport for JDK-8265836, which I'd like to
> > bring to OpenJDK 8u as the bug is present there too[2]. Note that the
> > OperatingSystemMXBean has been made container aware with JDK-8226575[1]
> > in 8u272 and better.
> > 
> > The OpenJDK 11u patch doesn't apply cleanly due to restructuring of the
> > code in later JDKs. The gist of the patch is still the same. One
> > addition of note is the mapfile-vers change for the new native method.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8247469
> > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8247469/jdk8/02/webrev/
> > 
> > Testing: Builds on Linux x86_64, Solaris Sparc, AIX.
> > ????????? Manually via the reproducer for JDK-8265836. Tier 1 on Linux x86_64
> > 
> > Thoughts?
> The backport looks good to me and it certainly looks necessary as a 
> prerequisite for backport for JDK-8265836. So count this as a review.

Thanks for the review, Andrew!

Cheers,
Severin


From sgehwolf at redhat.com  Tue Jul 13 17:05:39 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 13 Jul 2021 19:05:39 +0200
Subject: [8u] RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns
 incorrect CPU load inside a container
Message-ID: <a039e9420660b410d740a9bf515087ddf61c8467.camel@redhat.com>

Hi,

Please review this fix for cpu load reporting via the
OperatingSystemMXBean inside containers. With JDK-8226575[1] that mbean
has been made container aware and should therefore also report cpu load
according to the container settings. It currently reports incorrect
values. The backport depends on a backport of JDK-8247469, which has
been proposed here (already reviewed by Andrew Dinn):

https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-July/014106.html

The OpenJDK 11u patch doesn't apply cleanly since there have been
various refactorings in this area in later JDKs. The meat of the patch
is largely the same, though.

In particular changes to UnixOperatingSystem.c in JDK 11 have been done
in LinuxOperatingSystem.c in 8u, the package name in 8u is
sun.management over com.sun.management.internal (in 11u). Finally, the
new native method needs an entry in mapfile-vers.

Bug: https://bugs.openjdk.java.net/browse/JDK-8265836
webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8265836/jdk8/01/webrev/

Testing: Builds on Linux x86_64, Solaris Sparc, AIX. Tier 1 tests, no
         new regressions. Manual testing with the reproducer of the
         bug.

Thoughts?

Thanks,
Severin

[1] https://bugs.openjdk.java.net/browse/JDK-8226575


From adinn at redhat.com  Wed Jul 14 09:34:58 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 14 Jul 2021 10:34:58 +0100
Subject: [8u] RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns
 incorrect CPU load inside a container
In-Reply-To: <a039e9420660b410d740a9bf515087ddf61c8467.camel@redhat.com>
References: <a039e9420660b410d740a9bf515087ddf61c8467.camel@redhat.com>
Message-ID: <eebf6e58-bdb4-09d4-ef4b-2f8abea3a3e8@redhat.com>

Hi Severin,

On 13/07/2021 18:05, Severin Gehwolf wrote:

> Please review this fix for cpu load reporting via the
> OperatingSystemMXBean inside containers. . . .
Reviewed.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From wessel.van.norel at delgurth.com  Wed Jul 14 11:36:14 2021
From: wessel.van.norel at delgurth.com (Wessel van Norel)
Date: Wed, 14 Jul 2021 13:36:14 +0200
Subject: JDK8: Compile error introduced with backport JDK-8258780 for
 https://bugs.openjdk.java.net/browse/JDK-8078024
In-Reply-To: <62B89706-0804-44AD-AC7D-4627C679015D@getmailspring.com>
References: <6CB55570-EAD2-4530-94EF-DFEDD6D14B79@delgurth.com>
 <62B89706-0804-44AD-AC7D-4627C679015D@getmailspring.com>
Message-ID: <726408B8-B94A-47E9-A9D5-458F4A8B8379@delgurth.com>


> On 13 Jul 2021, at 18:47, Peter Zhelezniakov <peter.zhelezniakov at bell-sw.com> wrote:
> 
> Hi Wessel,
> I will look into this. I'm going to try to identify other fixes that might have played a role here.
> 
> Thanks!

Hi Peter,

Thanks. The differences between the Infer.java in jdk8 and Infer.java in jdk9 are unfortunately quite large. Hope my sized down testcase helps spotting where it goes wrong. If I can be of assistance, please let me know.

Kind regards,
Wessel van Norel


From aph at redhat.com  Thu Jul 15 10:42:11 2021
From: aph at redhat.com (Andrew Haley)
Date: Thu, 15 Jul 2021 11:42:11 +0100
Subject: RFR: CRITICAL: 8270533: AArch64: size_fits_all_mem_uses should return
 false if its output is a CAS
Message-ID: <afc0ef7e-d0ba-3109-9759-779c7c2d521e@redhat.com>

https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/54326de2a1d7 was back-ported
to 8u, but it contains a bug, and this bug causes hard crashes in production.

http://cr.openjdk.java.net/~aph/8270533/
https://bugs.openjdk.java.net/browse/JDK-8270533

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From adinn at redhat.com  Thu Jul 15 11:21:59 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 15 Jul 2021 12:21:59 +0100
Subject: RFR: CRITICAL: 8270533: AArch64: size_fits_all_mem_uses should
 return false if its output is a CAS
In-Reply-To: <afc0ef7e-d0ba-3109-9759-779c7c2d521e@redhat.com>
References: <afc0ef7e-d0ba-3109-9759-779c7c2d521e@redhat.com>
Message-ID: <4f40ce23-8141-2026-4382-2e4df6ef0d3e@redhat.com>



On 15/07/2021 11:42, Andrew Haley wrote:
> https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/54326de2a1d7 was back-ported
> to 8u, but it contains a bug, and this bug causes hard crashes in production.
> 
> http://cr.openjdk.java.net/~aph/8270533/
> https://bugs.openjdk.java.net/browse/JDK-8270533
Reviewed!

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From gnu.andrew at redhat.com  Thu Jul 15 12:47:24 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 15 Jul 2021 13:47:24 +0100
Subject: RFR: CRITICAL: 8270533: AArch64: size_fits_all_mem_uses should
 return false if its output is a CAS
In-Reply-To: <4f40ce23-8141-2026-4382-2e4df6ef0d3e@redhat.com>
References: <afc0ef7e-d0ba-3109-9759-779c7c2d521e@redhat.com>
 <4f40ce23-8141-2026-4382-2e4df6ef0d3e@redhat.com>
Message-ID: <20210715124724.GA284759@rincewind>

On 12:21 Thu 15 Jul     , Andrew Dinn wrote:
> 
> 
> On 15/07/2021 11:42, Andrew Haley wrote:
> > https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/54326de2a1d7 was back-ported
> > to 8u, but it contains a bug, and this bug causes hard crashes in production.
> > 
> > http://cr.openjdk.java.net/~aph/8270533/
> > https://bugs.openjdk.java.net/browse/JDK-8270533
> Reviewed!
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Red Hat Distinguished Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
> 

Thanks for the quick fix and review. I'll include this with the fixes for
the CPU and it'll trickle down from there to 8u-dev (so no need to push
anywhere now)
-- 
Andrew :)
Pronouns: he / him or they / them
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

From jdowland at redhat.com  Fri Jul 16 13:51:41 2021
From: jdowland at redhat.com (Jonathan Dowland)
Date: Fri, 16 Jul 2021 14:51:41 +0100
Subject: [8u] RFR: 8183369: RFC unconformity of HttpURLConnection with proxy
Message-ID: <20210716135141.htxwjqvgs4dybi7t@coil>

Hello,

Please consider the this fix for jdk8u, for parity with Oracle 8u311.

** Note that it depends upon the backport of JDK-8161016 first, which is
   marked jdk8u-fix-request. **

The original patch applied clean after two unshuffles, but the test
required an edit to function properly in jdk8u, due to changes around
logging in jigsaw, hence an RFR.

The change made to the unshuffled patch is

-         String HTTPLOG = "sun.net.www.protocol.http.HttpURLConnection";
+         String HTTPLOG = "";


Bug: https://bugs.openjdk.java.net/browse/JDK-8183369
Webrev: https://cr.openjdk.java.net/~jdowland/webrevs/JDK-8183369/webrev.00/

Tested on Linux x86_64 with packet captures to verify what was going on
in addition to the logging output (which the test relies upon).

Thanks,

-- 
???? Jonathan Dowland <jdowland at redhat.com>
Senior Software Engineer, OpenJDK, Red Hat


From ebaron at redhat.com  Mon Jul 19 21:35:54 2021
From: ebaron at redhat.com (Elliott Baron)
Date: Mon, 19 Jul 2021 17:35:54 -0400
Subject: [8u] RFR: 8238164: Update Apache Xerces to version 2.12.0
Message-ID: <2b3f0b01-69b6-94ce-e0bd-8863dbdf15e3@redhat.com>

Hi,

I'd like to request a review of 8238164 for 8u for parity with Oracle 
JDK 8u261.

8238164 is an 8-only bug, but has an extensive "relates to" list that I 
used as a guide for what to backport. I had considered copying over 
Xerces 2.12.0 en masse from JDK 11, but many of the related changes in 
8238164 extend beyond the Xerces package (e.g. Xalan, XML).

The chief concern I have with this backport is the lack of unit tests in 
the JAXP repo in 8u. Some of the referenced fixes below include new 
tests or changes to tests that were added in JDK 9 beginning with 
"8043084: XML JAXP unittest co-location".

I'd also like to note that there are minor changes to 
javax/xml/stream/XMLEventReader and javax/xml/stream/XMLStreamReader. 
The former adds an @Override tag, the other changes are all to 
documentation. I'm not sure if the override tag poses a problem to API 
compatibility.

One other minor issue is the @deprecated tag added to Xerces' internal 
serializer. This is not public API, but I was unsure whether to change 
the version from JDK 1.9 to JDK 1.8. I've just left it alone in this 
initial webrev. See: 
com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java.

The end of this mail contains a detailed list of related fixes mentioned 
in 8238164 that are included in this webrev, along with what 
modifications I made for them to apply to the 8u tree. The list also 
covers which of related fixes are not included in this webrev, and why not.

Bug: https://bugs.openjdk.java.net/browse/JDK-8238164
Webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8238164/webrev.00/

Testing: x86_64 build, jdk_tier1, jdk_other (includes javax/xml) tests

Thanks,
Elliott

---

Detailed list of included backported fixes:

8033980: Xerces Update: datatype XMLGregorianCalendarImpl and DurationImpl:
- One hunk already fixed by "8028363: 
XmlGregorianCalendarImpl.getTimeZone() bug when offset is less than 10 
minutes".

8035469: Xerces Update: EncodingMap does not recognize Java-style 
encodings Cp1141-Cp1149:
- Already fixed by "8068842: Better JAXP data handling".

8035577: Xerces Update: impl/xpath/regex/RangeToken.java:
- Applies cleanly.

8035437: Xerces Update: xml/serialize/DOMSerializerImpl
- com/sun/org/apache/xerces/internal/impl/XMLEntityManager
-- Copyright header differences
-- Import differences
- com/sun/org/apache/xml/internal/serialize/XMLSerializer
-- Copyright header differences
-- Import differences
-- Changed context due to previous backport of "8068842: Better JAXP 
data handling".
- com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer
-- Copyright header differences
-- Import differences
- com/sun/org/apache/xml/internal/serialize/DOMSerializerImpl
-- Context changes due to "8146961: Fix PermGen memory leaks caused by 
static final Exceptions" and "8011795: DOM Serializer prints stack 
traces to System.err"

8037259: xerces update: xpointer update
- Applies cleanly.

8041523: Xerces Update: Serializer improvements from Xalan
- com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet
-- Copyright header differences
-- Import differences
- com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl
-- Copyright header differences
-- Import differences
- com/sun/org/apache/xml/internal/serializer/EmptySerializer
-- Copyright header differences
-- Import differences

8035467: Xerces Update: Move to Xalan based DOM L3 serializer. Deprecate 
Xerces' native serializer.
- com/sun/org/apache/xml/internal/serialize/DOMSerializerImpl
-- @version tag in 8u context
- com/sun/org/apache/xml/internal/serialize/ElementState
-- Copyright header differences
- com/sun/org/apache/xml/internal/serialize/EncodingInfo
-- @version tag in 8u context
- com/sun/org/apache/xml/internal/serialize/Encodings
-- Copyright header differences
- com/sun/org/apache/xml/internal/serialize/HTMLdtd
-- Copyright header differences
- com/sun/org/apache/xml/internal/serialize/SerializerFactory
-- Copyright header differences

8053965: Xerces update breaks profile build
- Applies cleanly.

8037819: Xerces Update: jaxp/validation/XMLSchemaFactory
- com/sun/org/apache/xerces/internal/impl/Constants
-- Copyright header differences
- com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator
-- Copyright header differences
-- Context change due to "8186080: Transform XML interfaces"
- com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory
-- Copyright header differences
-- Context change due to "8186080: Transform XML interfaces"
- com/sun/org/apache/xerces/internal/parsers/XML11Configuration
-- Copyright header differences
-- Indentation differences due to "8149915: enabling 
validate-annotations feature for xsd schema with annotation causes NPE"
-- One line context difference due to "8186080: Transform XML interfaces"

8056202: Xerces Update: Catalog Resolver
- com/sun/org/apache/xml/internal/resolver/Catalog
-- Copyright header differences
-- Imports differ due to "8068842: Better JAXP data handling"
-- Affected code in one hunk removed by "8078427: More supportive home 
environment"
- com/sun/org/apache/xml/internal/resolver/CatalogEntry
-- Copyright header differences
-- Fields to patch changed by "8068842: Better JAXP data handling"
- com/sun/org/apache/xml/internal/resolver/CatalogManager
-- Patch context differs slightly due to "8186080: Transform XML interfaces"
- com/sun/org/apache/xml/internal/resolver/helpers/BootstrapResolver
-- Copyright header differences
-- Some fields already made final by "8068842: Better JAXP data handling"
- com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogReader
-- Copyright header differences
- com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogReader
-- Copyright header differences
-- "8068842: Better JAXP data handling" changes a field from Hashtable 
to Map
- com/sun/org/apache/xml/internal/resolver/tools/ResolvingParser
-- Context differs due to "8186080: Transform XML interfaces"

8036951: Xerces Update: XMLSchemaValidator.java and XMLSchemaLoader.java
- com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl
-- Copyright header differences
-- Import differences from "8186080: Transform XML interfaces"
- com/sun/org/apache/xerces/internal/impl/XMLEntityManager
-- Import differences from "8068842: Better JAXP data handling"
-- Some changes already present from backport of "8039533: Higher 
resolution resolvers"
- com/sun/org/apache/xerces/internal/impl/XMLErrorReporter
-- Copyright header differences
- com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader
-- Copyright header differences
-- Context differs due to "8068842: Better JAXP data handling"
- com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator
-- Import differences from "8068842: Better JAXP data handling"
-- Context differences "8186080: Transform XML interfaces"
-- Some changes superseded by "8068842: Better JAXP data handling"
- com/sun/org/apache/xerces/internal/util/XMLAttributesImpl
-- Copyright header differences

8080906: Develop test for Xerces Update: DOM L3 Serializer
- Skipped. No tests in 8u jaxp repo. Do we backport them?

8080908: Develop test for Xerces Update: XPointer
- Skipped. No tests in 8u jaxp repo

8080907: Develop test for Xerces Update: XML Schema Validation
- Skipped. No tests in 8u jaxp repo

8080266: Failed to create CharInfo due to ResourceBundle update for modules
- test/javax/xml/jaxp/unittest/org/w3c/dom/ls/LSSerializerTest
-- No tests in 8u jaxp repo

8142900: Xerces Update: Xerces XPath
- com/sun/org/apache/xerces/internal/impl/xpath/regex/Token
-- Context differs due to lambda usage in "8068842: Better JAXP data 
handling"

8142463: Xml schema validation failing after Xerces update; maxOccurs 
ignored
- test/javax/xml/jaxp/unittest/validation/tck
-- Directory not included in backport, no tests in 8u

8167002: JAXP schema validator: Use HashSet instead of ArrayList for 
tracking XML IDs
- Applies cleanly

8069098: StAX produces the wrong event stream (Dep for 8169450)
- test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/BugTest
-- No tests in 8u jaxp repo

8169450: StAX parse error if there is a newline in xml declaration
- com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl
-- Different field name because "8170556: Warnings cleanup related to 
JDK-8167340" not in 8u.
- test/javax/xml/jaxp/unittest/parsers/BaseParsingTest
-- No tests in 8u jaxp repo

8150256: removing xerces-related dead code
- com/sun/org/apache/xerces/internal/xinclude/XPointerElementHandler
- com/sun/org/apache/xerces/internal/xinclude/XPointerFramework
-- Didn't apply cleanly, but files are deleted

8181150: Fix lint warnings in JAXP repo: rawtypes and unchecked
- Didn't backport. Too big.

8038043: Xerces Update: XInclude update
- com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl
-- Copyright header differences.
- com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser
-- Copyright header differences.
- com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler
-- Copyright header differences.
-- Import order different, and Stack fields not parameterized, because 
"8181150: Fix lint warnings in JAXP repo: rawtypes and unchecked" not 
backported.
-- ObjectFactory import retained because "8166398: CatalogSupport tests 
need to be fixed" not in 8u, which removed its usage in this class.
- com/sun/org/apache/xerces/internal/xinclude/XIncludeTextReader
-- Copyright header differences.
- test/javax/xml/jaxp/unittest/common/EncodingErrorsReportingTest
- test/javax/xml/jaxp/unittest/parsers/BaseParsingTest
-- No tests in 8u jaxp repo

8213117: adoptNode corrupts attribute values
- com/sun/org/apache/xerces/internal/dom/CoreDocumentImpl
-- No @LastModified tag to modify, introduced in "8193568: @LastModified 
tag in license header".
- test/javax/xml/jaxp/unittest/dom/DocumentTest
-- No tests in 8u jaxp repo

8222415: Xerces 2.12.0: Parsing Configuration
- com/sun/org/apache/xerces/internal/impl/XMLEntityManager
-- Copyright header differences.
-- No @LastModified tag to modify, introduced in "8193568: @LastModified 
tag in license header".
-- Context differs due to no backport of "8158084: Catalog API: JAXP XML 
Processor Support".
-- Some lines differ due to no backport of "8181154: Fix lint warnings 
in JAXP repo: deprecation" and "8170556: Warnings cleanup related to 
JDK-8167340". End result is the same.
- test/javax/xml/jaxp/unittest/parsers/BaseParsingTest
-- No tests in 8u jaxp repo

8222743: Xerces 2.12.0: DOM Implementation
- com/sun/org/apache/xerces/internal/dom/AttrImpl
-- Copyright header differences.
-- Import differences due to no backport of "8181154: Fix lint warnings 
in JAXP repo: deprecation".
-- No "ElementTraversal" condition since "8138721: ElementTraversal: 
javadoc warning; also, hasFeature shall return true" is not in 8u.
-- getFeature method has extra code removed by "8042244: Re-examine the 
supportedness of non-SE org.w3c.dom.** API".
-- Context for doc change differs because of no "8181154: Fix lint 
warnings in JAXP repo: deprecation".
-- 2 line difference because of no "8130051: Cleanup usage of reflection 
in jaxp" in 8u.
- com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl
-- Copyright header differences.
-- Import differences due to lack of "8181150: Fix lint warnings in JAXP 
repo: rawtypes and unchecked" and "8158084: Catalog API: JAXP XML 
Processor Support".
-- No @LastModified tag to modify, introduced in "8193568: @LastModified 
tag in license header".
-- Features differ due to no "8158084: Catalog API: JAXP XML Processor 
Support".
-- One line type difference from "8181150: Fix lint warnings in JAXP 
repo: rawtypes and unchecked".
- com/sun/org/apache/xerces/internal/dom/DOMNormalizer
-- Copyright header differences.
-- No @LastModified tag to modify, introduced in "8193568: @LastModified 
tag in license header".
-- Import order differs due to lack of "8181150: Fix lint warnings in 
JAXP repo: rawtypes and unchecked".
-- Difference in 8u version of "8146961: Fix PermGen memory leaks caused 
by static final Exceptions" causes a slight difference in context.
-- Removed line differs because of "8158204: accessExternalSchema 
property handling is inconsistent and differs from spec." absent in 8u.
-- Method call in two places replaced with non-deprecated equivalent by 
"8181154: Fix lint warnings in JAXP repo: deprecation", which is not in 8u.
- com/sun/org/apache/xerces/internal/dom/ElementImpl
-- This patch reverts some formatting changes done by "8135283: DOM API 
update: Element Traversal Specification", which is not backported. These 
changes are removed where applicable.
-- setOwnerDocument changed from package-private to protected, as 
required by this patch. Was made protected in 11u by "8135283: DOM API 
update: Element Traversal Specification", which is not backported.
- com/sun/org/apache/xerces/internal/dom/NodeImpl
-- Copyright header differences.
- com/sun/org/apache/xerces/internal/dom/ParentNode
-- Version tag still present in context because "8048021: Remove 
@version tag in jaxp repo" not in 8u.
- com/sun/org/apache/xerces/internal/util/ParserConfigurationSettings
-- Copyright header differences.
-- Version tag still present in context because "8048021: Remove 
@version tag in jaxp repo" not in 8u.
-- Minor code differences due to "8158084: Catalog API: JAXP XML 
Processor Support" not in 8u.
- test/javax/xml/jaxp/unittest/dom/DocumentTest
-- No tests in 8u jaxp repo

8222991: Xerces 2.12.0: Validation
- com/sun/org/apache/xerces/internal/impl/dv/xs/TypeValidator
-- Added a getSystemProperty(final String propName, final String def) to 
com.sun.org.apache.xerces.internal.utils.SecuritySupport, in place of 
jdk.xml.internal.SecuritySupport, because the latter is non-public in 8u.
- com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAbstractTraverser
-- Add java.util.List import, added in 11+ by "8181150: Fix lint 
warnings in JAXP repo: rawtypes and unchecked".
- 
com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDComplexTypeTraverser
-- Copyright header differences.
-- Version tag still present in context because "8048021: Remove 
@version tag in jaxp repo" not in 8u.
- com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler
-- No @LastModified tag to modify, introduced in "8193568: @LastModified 
tag in license header".
-- Some raw types still used in context due to no "8181150: Fix lint 
warnings in JAXP repo: rawtypes and unchecked" in 8u.
-- Converting some ArrayLists in addNewImportedGrammars where Vectors 
are expected in 8u code due to lack of "8181150: Fix lint warnings in 
JAXP repo: rawtypes and unchecked".
- test/javax/xml/jaxp/unittest/validation/SchemaTest
-- No tests in 8u jaxp repo

8223658: Performance regression of XML.validation in 13-b19
- com/sun/org/apache/xerces/internal/dom/DeferredDocumentImpl
-- Copyright header differences.
-- No @LastModified tag to modify, introduced in "8193568: @LastModified 
tag in license header".

8225005: Xerces 2.12.0: License file
- Moved version update from src/java.xml/share/legal/xerces.md to 
THIRD_PARTY_README.


From gnu.andrew at redhat.com  Wed Jul 21 04:45:05 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 21 Jul 2021 05:45:05 +0100
Subject: OpenJDK 8u302 Released
Message-ID: <20210721044505.GA738682@rincewind>

We are pleased to announce the release of OpenJDK 8u302.

The source tarball is available from:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u302-ga.tar.xz

The tarball is accompanied by a digital signature available at:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u302-ga.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint = CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

ab50669afd85086ba451cbc1560ae76e9bc7fc3c9c46e3d37ee5c6a48bb30124  openjdk8u302-ga.tar.xz
6642f62a5eb3c66f4118e4534a0db763f32ba166ea58a4cbb508b48d7d16ce25  openjdk8u302-ga.tar.xz.sig

The checksums can be downloaded from:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u302-ga.sha256

New in release OpenJDK 8u302 (2021-07-20):
===========================================
Live versions of these release notes can be found at:
  * https://bitly.com/openjdk8u302
  * https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u302.txt

* Security fixes
  - JDK-8256157: Improve bytecode assembly
  - JDK-8256491: Better HTTP transport
  - JDK-8258432, CVE-2021-2341: Improve file transfers
  - JDK-8260453: Improve Font Bounding
  - JDK-8260960: Signs of jarsigner signing
  - JDK-8260967, CVE-2021-2369: Better jar file validation
  - JDK-8262380: Enhance XML processing passes
  - JDK-8262403: Enhanced data transfer
  - JDK-8262410: Enhanced rules for zones
  - JDK-8262477: Enhance String Conclusions
  - JDK-8262967: Improve Zip file support
  - JDK-8264066, CVE-2021-2388: Enhance compiler validation
  - JDK-8264079: Improve abstractions
  - JDK-8264460: Improve NTLM support
* Other changes
  - JDK-6878250: (so) IllegalBlockingModeException thrown when reading from a closed SocketChannel's InputStream
  - JDK-6990210: [TEST_BUG] EventDispatchThread/HandleExceptionOnEDT/HandleExceptionOnEDT.java fails on gnome
  - JDK-7059970: Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file
  - JDK-7106851: Test should not use System.exit
  - JDK-8019470: Changes needed to compile JDK 8 on MacOS with clang compiler
  - JDK-8028618: [TEST BUG] javax/swing/JScrollBar/bug4202954/bug4202954.java fails
  - JDK-8030123: java/beans/Introspector/Test8027648.java fails
  - JDK-8032050: Clean up for java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java
  - JDK-8033289: clang: clean up unused function warning
  - JDK-8034856: gcc warnings compiling src/solaris/native/sun/security/pkcs11
  - JDK-8034857: gcc warnings compiling src/solaris/native/sun/management
  - JDK-8035000: clean up ActivationLibrary.DestroyThread
  - JDK-8035054: JarFacade.c should not include ctype.h
  - JDK-8035287: gcc warnings compiling various libraries files
  - JDK-8036095: RMI tests using testlibrary.RMID and testlibrary.JavaVM do not pass through vmoptions
  - JDK-8037825: Fix warnings and enable "warnings as errors" in serviceability native libraries
  - JDK-8042891: Format issues embedded in macros for two g1 source files
  - JDK-8043264: hsdis library not picked up correctly on expected paths
  - JDK-8043646: libosxapp.dylib fails to build on Mac OS 10.9 with clang
  - JDK-8047939: [TESTBUG] Rewrite test/runtime/8001071/Test8001071.sh
  - JDK-8055754: filemap.cpp does not compile with clang
  - JDK-8064909: FragmentMetaspace.java got OutOfMemoryError
  - JDK-8066508: JTReg tests timeout on slow devices when run using JPRT
  - JDK-8066807: langtools/test/Makefile should use -agentvm not -samevm
  - JDK-8071374: -XX:+PrintAssembly -XX:+PrintSignatureHandlers crash fastdebug VM with assert(limit == __null || limit <= nm->code_end()) in RelocIterator::initialize
  - JDK-8073446: TimeZone getOffset API does not return a dst offset between years 2038-2137
  - JDK-8074835: Resolve disabled warnings for libj2gss
  - JDK-8074836: Resolve disabled warnings for libosxkrb5
  - JDK-8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction
  - JDK-8077364: "if( !this )" construct prevents build on Xcode 6.3
  - JDK-8078855: [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in WindowsClassicLookAndFeel
  - JDK-8081764: [TEST_BUG] Test javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on Windows, Solaris Sparcv9 and Linux but passes on MacOSX
  - JDK-8129511: PlatformMidi.c:83 uses malloc without malloc header
  - JDK-8130308: Too low memory usage in TestPromotionFromSurvivorToTenuredAfterMinorGC.java
  - JDK-8130430: [TEST_BUG] remove unnecessary internal calls from javax/swing/JRadioButton/8075609/bug8075609.java
  - JDK-8132148: G1 hs_err region dump legend out of sync with region values
  - JDK-8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on embedded
  - JDK-8134672: [TEST_BUG] Some tests should check isDisplayChangeSupported
  - JDK-8134883: C1 hard crash in range check elimination in Nashorn test262parallel
  - JDK-8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw
  - JDK-8138820: JDK Hotspot build fails with Xcode 7.0.1
  - JDK-8151786: [TESTBUG] java/beans/XMLEncoder/Test4625418.java timed out intermittently
  - JDK-8159898: Negative array size in java/beans/Introspector/Test8027905.java
  - JDK-8166046: [TESTBUG] compiler/stringopts/TestStringObjectInitialization.java fails with OOME
  - JDK-8166724: gc/g1/TestHumongousShrinkHeap.java fails with OOME
  - JDK-8172188: JDI tests fail due to "permission denied" when creating temp file
  - JDK-8177809: File.lastModified() is losing milliseconds (always ends in 000)
  - JDK-8178403: DirectAudio in JavaSound may hang and leak
  - JDK-8180478: tools/launcher/MultipleJRE.sh fails on Windows because of extra-''
  - JDK-8183910: gc/arguments/TestAggressiveHeap.java fails intermittently
  - JDK-8190332: PngReader throws NegativeArraySizeException/OOM error when IHDR width is very large
  - JDK-8190679: java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"
  - JDK-8191955: AArch64: incorrect prefetch distance causes an internal error
  - JDK-8196092: javax/swing/JComboBox/8032878/bug8032878.java fails
  - JDK-8199265: java/util/Arrays/TimSortStackSize2.java fails with OOM
  - JDK-8200550: Xcode 9.3 produce warning -Wexpansion-to-defined
  - JDK-8202299: Java Keystore fails to load PKCS12/PFX certificates created in WindowsServer2016
  - JDK-8203196: C1 emits incorrect code due to integer overflow in _tableswitch keys
  - JDK-8205014: com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java failed with "Read timed out"
  - JDK-8206243: java -XshowSettings fails if memory.limit_in_bytes overflows LONG.max
  - JDK-8206925: Support the certificate_authorities extension
  - JDK-8209996: [PPC64] Fix JFR profiling
  - JDK-8214345: infinite recursion while checking super class
  - JDK-8217230: assert(t == t_no_spec) failure in NodeHash::check_no_speculative_types()
  - JDK-8217348: assert(thread->is_Java_thread()) failed: just checking
  - JDK-8225081: Remove Telia Company CA certificate expiring in April 2021
  - JDK-8225116: Test OwnedWindowsLeak.java intermittently fails
  - JDK-8228757: Fail fast if the handshake type is unknown
  - JDK-8230428: Cleanup dead CastIP node code in formssel.cpp
  - JDK-8231631: sun/net/ftp/FtpURLConnectionLeak.java fails intermittently with NPE
  - JDK-8231841: AArch64: debug.cpp help() is missing an AArch64 line for pns
  - JDK-8231949: [PPC64, s390]: Make async profiling more reliable
  - JDK-8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()
  - JDK-8239053: [8u] clean up undefined-var-template warnings
  - JDK-8239400: [8u] clean up undefined-var-template warnings
  - JDK-8241649: Optimize Character.toString
  - JDK-8241829: Cleanup the code for PrinterJob on windows
  - JDK-8242565: Policy initialization issues when the denyAfter constraint is enabled
  - JDK-8243559: Remove root certificates with 1024-bit keys
  - JDK-8247350: [aarch64] assert(false) failed: wrong size of mach node
  - JDK-8249142: java/awt/FontClass/CreateFont/DeleteFont.sh is unstable
  - JDK-8249278: Revert JDK-8226253 which breaks the spec of AccessibleState.SHOWING for JList
  - JDK-8250876: Fix issues with cross-compile on macos
  - JDK-8252883: AccessDeniedException caused by delayed file deletion on Windows
  - JDK-8253375: OSX build fails with Xcode 12.0 (12A7209)
  - JDK-8254631: Better support ALPN byte wire values in SunJSSE
  - JDK-8255086: Update the root locale display names
  - JDK-8255734: VM should ignore SIGXFSZ on ppc64, s390 too
  - JDK-8256818: SSLSocket that is never bound or connected leaks socket resources
  - JDK-8257039: [8u] GenericTaskQueue destructor is incorrect
  - JDK-8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks
  - JDK-8257884: Re-enable sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test
  - JDK-8257997: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again reports leaks after JDK-8257884
  - JDK-8257999: Parallel GC crash in gc/parallel/TestDynShrinkHeap.java: new region is not in covered_region
  - JDK-8258419: RSA cipher buffer cleanup
  - JDK-8258669: fastdebug jvm crashes when do event based tracing for monitor inflation
  - JDK-8258753: StartTlsResponse.close() hangs due to synchronization issues
  - JDK-8259271: gc/parallel/TestDynShrinkHeap.java still fails "assert(covered_region.contains(new_memregion)) failed: new region is not in covered_region"
  - JDK-8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect
  - JDK-8259886: Improve SSL session cache performance and scalability
  - JDK-8260029: aarch64: fix typo in verify_oop_array
  - JDK-8260236: better init AnnotationCollector _contended_group
  - JDK-8260255: C1: LoopInvariantCodeMotion constructor can leave some fields uninitialized
  - JDK-8260484: CheckExamples.java / NoJavaLangTest.java fail with jtreg 4.2
  - JDK-8260704: ParallelGC: oldgen expansion needs release-store for _end
  - JDK-8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding
  - JDK-8261867: Backport relevant test changes & additions from JDK-8130125
  - JDK-8262110: DST starts from incorrect time in 2038
  - JDK-8262446: DragAndDrop hangs on Windows
  - JDK-8262726: AArch64: C1 StubAssembler::call_RT can corrupt stack
  - JDK-8262730: Enable jdk8u MacOS external debug symbols
  - JDK-8262864: No debug symbols in image for Windows --with-native-debug-symbols=external
  - JDK-8263061: copy wrong unpack200 debuginfo to bin directory after 8252395
  - JDK-8263504: Some OutputMachOpcodes fields are uninitialized
  - JDK-8263600: change rmidRunning to a simple lookup
  - JDK-8264509: jdk8u MacOS zipped debug symbols won't build
  - JDK-8264562: assert(verify_field_bit(1)) failed: Attempting to write an uninitialized event field: type
  - JDK-8264640: CMS ParScanClosure misses a barrier
  - JDK-8264816: Weak handles leak causes GC to take longer
  - JDK-8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod
  - JDK-8265666: Enable AIX build platform to make external debug symbols
  - JDK-8265832: runtime/StackGap/testme.sh fails to compile in 8u
  - JDK-8265988: Fix sun/text/IntHashtable/Bug4170614 for JDK 8u
  - JDK-8266191: Missing aarch64 parts of JDK-8181872 (C1: possible overflow when strength reducing integer multiply by constant)
  - JDK-8266723: JFR periodic events are causing extra allocations
  - JDK-8266929: Unable to use algorithms from 3p providers
  - JDK-8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash
  - JDK-8267426: MonitorVmStartTerminate test timed out on Embedded VM
  - JDK-8267545: [8u] Enable Xcode 12 builds on macOS
  - JDK-8267689: [aarch64] Crash due to bad shift in indirect addressing mode
  - JDK-8268444: keytool -v -list print is incorrect after backport JDK-8141457
  - JDK-8269388: Default build of OpenJDK 8 fails on newer GCCs with warnings as errors on format-overflow
  - JDK-8269468: JDK-8269388 breaks the build on older GCCs
  - JDK-8270533: AArch64: size_fits_all_mem_uses should return false if its output is a CAS

Notes on individual issues:
===========================

security-libs/java.security:

JDK-8256902: Removed Root Certificates with 1024-bit Keys
=========================================================
The following root certificates with weak 1024-bit RSA public keys
have been removed from the `cacerts` keystore:

Alias Name: thawtepremiumserverca [jdk]
Distinguished Name: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA

Alias Name: verisignclass2g2ca [jdk]
Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

Alias Name: verisignclass3ca [jdk]
Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

Alias Name: verisignclass3g2ca [jdk]
Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

Alias Name: verisigntsaca [jdk]
Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA

JDK-8261361: Removed Telia Company's Sonera Class2 CA certificate
=================================================================

The following root certificate have been removed from the cacerts truststore:

Alias Name: soneraclass2ca
Distinguished Name: CN=Sonera Class2 CA, O=Sonera, C=FI

security-libs/javax.net.ssl:

JDK-8257548: Improve Encoding of TLS Application-Layer Protocol Negotiation (ALPN) Values
=========================================================================================
Certain TLS ALPN values couldn't be properly read or written by the
SunJSSE provider. This is due to the choice of Strings as the API
interface and the undocumented internal use of the UTF-8 Character Set
which converts characters larger than U+00007F (7-bit ASCII) into
multi-byte arrays that may not be expected by a peer.

ALPN values are now represented using the network byte representation
expected by the peer, which should require no modification for
standard 7-bit ASCII-based character Strings. However, SunJSSE now
encodes/decodes String characters as 8-bit ISO_8859_1/LATIN-1
characters.  This means applications that used characters above
U+000007F that were previously encoded using UTF-8 may need to either
be modified to perform the UTF-8 conversion, or set the Java security
property `jdk.tls.alpnCharset` to "UTF-8" revert the behavior.

See the updated guide at
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/alpn.html
for more information.

JDK-8244460: Support for certificate_authorities Extension
==========================================================
The "certificate_authorities" extension is an optional extension
introduced in TLS 1.3. It is used to indicate the certificate
authorities (CAs) that an endpoint supports and should be used by the
receiving endpoint to guide certificate selection.

With this JDK release, the "certificate_authorities" extension is
supported for TLS 1.3 in both the client and the server sides.  This
extension is always present for client certificate selection, while it
is optional for server certificate selection.

Applications can enable this extension for server certificate
selection by setting the `jdk.tls.client.enableCAExtension` system
property to `true`.  The default value of the property is `false`.

Note that if the client trusts more CAs than the size limit of the
extension (less than 2^16 bytes), the extension is not enabled.  Also,
some server implementations do not allow handshake messages to exceed
2^14 bytes.  Consequently, there may be interoperability issues when
`jdk.tls.client.enableCAExtension` is set to `true` and the client
trusts more CAs than the server implementation limit.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
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

From gnu.andrew at redhat.com  Wed Jul 21 17:14:50 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 21 Jul 2021 18:14:50 +0100
Subject: [8u] RFR: 8238164: Update Apache Xerces to version 2.12.0
In-Reply-To: <2b3f0b01-69b6-94ce-e0bd-8863dbdf15e3@redhat.com>
References: <2b3f0b01-69b6-94ce-e0bd-8863dbdf15e3@redhat.com>
Message-ID: <20210721171450.GC754562@rincewind>

On 17:35 Mon 19 Jul     , Elliott Baron wrote:
> Hi,
> 
> I'd like to request a review of 8238164 for 8u for parity with Oracle JDK
> 8u261.
> 
> 8238164 is an 8-only bug, but has an extensive "relates to" list that I used
> as a guide for what to backport. I had considered copying over Xerces 2.12.0
> en masse from JDK 11, but many of the related changes in 8238164 extend
> beyond the Xerces package (e.g. Xalan, XML).
> 
> The chief concern I have with this backport is the lack of unit tests in the
> JAXP repo in 8u. Some of the referenced fixes below include new tests or
> changes to tests that were added in JDK 9 beginning with "8043084: XML JAXP
> unittest co-location".
> 
> I'd also like to note that there are minor changes to
> javax/xml/stream/XMLEventReader and javax/xml/stream/XMLStreamReader. The
> former adds an @Override tag, the other changes are all to documentation.
> I'm not sure if the override tag poses a problem to API compatibility.
> 
> One other minor issue is the @deprecated tag added to Xerces' internal
> serializer. This is not public API, but I was unsure whether to change the
> version from JDK 1.9 to JDK 1.8. I've just left it alone in this initial
> webrev. See:
> com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java.
> 
> The end of this mail contains a detailed list of related fixes mentioned in
> 8238164 that are included in this webrev, along with what modifications I
> made for them to apply to the 8u tree. The list also covers which of related
> fixes are not included in this webrev, and why not.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8238164
> Webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8238164/webrev.00/
> 
> Testing: x86_64 build, jdk_tier1, jdk_other (includes javax/xml) tests
> 
> Thanks,
> Elliott
> 
> ---

Are you saying this webrev is all (or most of) the fixes you listed merged
together?

I don't know how to even begin reviewing such a thing. Can we not just
backport the fixes individually, so they can be easily reviewed?

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
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

From gnu.andrew at redhat.com  Wed Jul 21 17:18:52 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 21 Jul 2021 18:18:52 +0100
Subject: [8u] RFR: 8187450: JNI local refs exceeds capacity warning in
 NetworkInterface::getAll
In-Reply-To: <20210325095819.fxhu3d5bjcsssxyl@qusp>
References: <20210325095819.fxhu3d5bjcsssxyl@qusp>
Message-ID: <20210721171852.GD754562@rincewind>

On 09:58 Thu 25 Mar     , Jonathan Dowland wrote:
> Good morning,
> 
> I'm requesting a review of a backport of JDK-8187450 to 8u.
> 
> The patch (from 11u backport) does not apply cleanly, just one hunk due
> to extra #if defined(AF_INET6) in the context.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8187450
> Webrev: https://cr.openjdk.java.net/~jdowland/webrevs/JDK-8187450/webrev.jdk8u.00/
> 
> Testing notes:
> 
> test/java/net/NetworkInterface/Test.java passes.
> 
> I had two tier1 failures that I am confident are unrelated, and also
> fail for me against a known-good 8u:
> 
>     tools/javac/diags/CheckExamples.java: provide examples of code that generate diagnostics
>     tools/javac/fatalErrors/NoJavaLangTest.java: Verify that the compiler does not crash when java.lang is not
> they fail with jtreg
> 
> The rest of tier1 passed.
> 
> If you want to check out the impact this change makes, on a Linux host
> you can use network namespaces to isolate the number of network
> interfaces that are visible to Java, and steadily add more (virtual)
> interfaces. There are some shell script snippets in the original GitHub
> PR that might be useful:
> 
>     https://github.com/openjdk/jdk/pull/2963
> 
> My results comparing before/after this patch for 8u are
> 
> baseline, 2 network interfaces sufficient to breach the local refs limit:
> 
>     $ sudo ip netns exec jbase ip link show | grep UP | wc -l
>      2
>     $ sudo ip netns exec jbase $JAVA_HOME/bin/java -Xcheck:jni NITest
>     WARNING: JNI local refs: 33, exceeds capacity: 32
> 	at java.net.NetworkInterface.getAll(Native Method)
> 	at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:355)
> 	at NITest.main(NITest.java:4)
> 
> after patch, the first local refs breach occurs with 5 interfaces:
> 
>     ...
>     $ ./addif.sh 4
>     5 interfaces
>     $ sudo ip netns exec jbase $JAVA_HOME/bin/java -Xcheck:jni NITest
>     WARNING: JNI local refs: 33, exceeds capacity: 32
>             at java.net.NetworkInterface.getAll(Native Method)
>             at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:355)
>             at NITest.main(NITest.java:4)
> 
> after patch, it takes 10 interfaces to breach the next limit
> 
>     ...
>     $ ./addif.sh 9
>     10 interfaces
>     $ sudo ip netns exec jbase $JAVA_HOME/bin/java -Xcheck:jni NITest
>     WARNING: JNI local refs: 33, exceeds capacity: 32
>             at java.net.NetworkInterface.getAll(Native Method)
>             at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:355)
>             at NITest.main(NITest.java:4)
>     WARNING: JNI local refs: 66, exceeds capacity: 65
>             at java.net.NetworkInterface.getAll(Native Method)
>             at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:355)
>             at NITest.main(NITest.java:4)
> 
> 
> -- 
> ???? Jonathan Dowland <jdowland at redhat.com>
> Senior Software Engineer, OpenJDK, Red Hat
> 

Backport looks fine to me. Pretty much close to clean.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
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

From ebaron at redhat.com  Wed Jul 21 17:32:35 2021
From: ebaron at redhat.com (Elliott Baron)
Date: Wed, 21 Jul 2021 13:32:35 -0400
Subject: [8u] RFR: 8238164: Update Apache Xerces to version 2.12.0
In-Reply-To: <20210721171450.GC754562@rincewind>
References: <2b3f0b01-69b6-94ce-e0bd-8863dbdf15e3@redhat.com>
 <20210721171450.GC754562@rincewind>
Message-ID: <671c0c8b-4a57-01e1-c11e-445b56c963d8@redhat.com>

Hi Andrew,

On 2021-07-21 1:14 p.m., Andrew Hughes wrote:
> On 17:35 Mon 19 Jul     , Elliott Baron wrote:
>> Hi,
>>
>> I'd like to request a review of 8238164 for 8u for parity with Oracle JDK
>> 8u261.
>>
>> 8238164 is an 8-only bug, but has an extensive "relates to" list that I used
>> as a guide for what to backport. I had considered copying over Xerces 2.12.0
>> en masse from JDK 11, but many of the related changes in 8238164 extend
>> beyond the Xerces package (e.g. Xalan, XML).
>>
>> The chief concern I have with this backport is the lack of unit tests in the
>> JAXP repo in 8u. Some of the referenced fixes below include new tests or
>> changes to tests that were added in JDK 9 beginning with "8043084: XML JAXP
>> unittest co-location".
>>
>> I'd also like to note that there are minor changes to
>> javax/xml/stream/XMLEventReader and javax/xml/stream/XMLStreamReader. The
>> former adds an @Override tag, the other changes are all to documentation.
>> I'm not sure if the override tag poses a problem to API compatibility.
>>
>> One other minor issue is the @deprecated tag added to Xerces' internal
>> serializer. This is not public API, but I was unsure whether to change the
>> version from JDK 1.9 to JDK 1.8. I've just left it alone in this initial
>> webrev. See:
>> com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java.
>>
>> The end of this mail contains a detailed list of related fixes mentioned in
>> 8238164 that are included in this webrev, along with what modifications I
>> made for them to apply to the 8u tree. The list also covers which of related
>> fixes are not included in this webrev, and why not.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238164
>> Webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8238164/webrev.00/
>>
>> Testing: x86_64 build, jdk_tier1, jdk_other (includes javax/xml) tests
>>
>> Thanks,
>> Elliott
>>
>> ---
> 
> Are you saying this webrev is all (or most of) the fixes you listed merged
> together?
> 
> I don't know how to even begin reviewing such a thing. Can we not just
> backport the fixes individually, so they can be easily reviewed?
> 

Yes, this is an all-in-one webrev. 8238164 led me to believe this was 
the approach taken by Oracle, just based on the information in JBS. The 
individual fixes do not show as being backported to Oracle JDK 8.

Nevertheless, it's no problem to propose these fixes one at a time. I 
understand it will be easier to review that way.

Thanks,
Elliott


From kalinshi at tencent.com  Thu Jul 29 03:56:36 2021
From: kalinshi at tencent.com (=?gb2312?B?a2FsaW5zaGkoyqm72yk=?=)
Date: Thu, 29 Jul 2021 03:56:36 +0000
Subject: =?gb2312?B?u9i4tDogW0ludGVybmV0XU9wZW5KREsgOHUzMDIgUmVsZWFzZWQ=?=
In-Reply-To: <20210721044505.GA738682@rincewind>
References: <20210721044505.GA738682@rincewind>
Message-ID: <bd9464eb3bd54eea9c74f15f169ccff8@tencent.com>

Hi, 

https://bugs.openjdk.java.net/browse/JDK-8263145 is resolved as fixed in 8u301.

Expect fix is 
-            rmid.shutdown(rmidPort);
+            rmid.destroy();

But fix doesn't exist in http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/6ad1494ea3f4/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
This cause test fail after backport https://bugs.openjdk.java.net/browse/JDK-8035000.

Regards
Hui

-----????-----
???: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> ?? Andrew Hughes
????: 2021?7?21? 12:45
???: jdk8u-dev at openjdk.java.net
??: [Internet]OpenJDK 8u302 Released

We are pleased to announce the release of OpenJDK 8u302.

The source tarball is available from:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u302-ga.tar.xz

The tarball is accompanied by a digital signature available at:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u302-ga.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

ab50669afd85086ba451cbc1560ae76e9bc7fc3c9c46e3d37ee5c6a48bb30124  openjdk8u302-ga.tar.xz
6642f62a5eb3c66f4118e4534a0db763f32ba166ea58a4cbb508b48d7d16ce25  openjdk8u302-ga.tar.xz.sig

The checksums can be downloaded from:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u302-ga.sha256

New in release OpenJDK 8u302 (2021-07-20):
===========================================
Live versions of these release notes can be found at:
  * https://bitly.com/openjdk8u302
  * https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u302.txt

* Security fixes
  - JDK-8256157: Improve bytecode assembly
  - JDK-8256491: Better HTTP transport
  - JDK-8258432, CVE-2021-2341: Improve file transfers
  - JDK-8260453: Improve Font Bounding
  - JDK-8260960: Signs of jarsigner signing
  - JDK-8260967, CVE-2021-2369: Better jar file validation
  - JDK-8262380: Enhance XML processing passes
  - JDK-8262403: Enhanced data transfer
  - JDK-8262410: Enhanced rules for zones
  - JDK-8262477: Enhance String Conclusions
  - JDK-8262967: Improve Zip file support
  - JDK-8264066, CVE-2021-2388: Enhance compiler validation
  - JDK-8264079: Improve abstractions
  - JDK-8264460: Improve NTLM support
* Other changes
  - JDK-6878250: (so) IllegalBlockingModeException thrown when reading from a closed SocketChannel's InputStream
  - JDK-6990210: [TEST_BUG] EventDispatchThread/HandleExceptionOnEDT/HandleExceptionOnEDT.java fails on gnome
  - JDK-7059970: Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file
  - JDK-7106851: Test should not use System.exit
  - JDK-8019470: Changes needed to compile JDK 8 on MacOS with clang compiler
  - JDK-8028618: [TEST BUG] javax/swing/JScrollBar/bug4202954/bug4202954.java fails
  - JDK-8030123: java/beans/Introspector/Test8027648.java fails
  - JDK-8032050: Clean up for java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java
  - JDK-8033289: clang: clean up unused function warning
  - JDK-8034856: gcc warnings compiling src/solaris/native/sun/security/pkcs11
  - JDK-8034857: gcc warnings compiling src/solaris/native/sun/management
  - JDK-8035000: clean up ActivationLibrary.DestroyThread
  - JDK-8035054: JarFacade.c should not include ctype.h
  - JDK-8035287: gcc warnings compiling various libraries files
  - JDK-8036095: RMI tests using testlibrary.RMID and testlibrary.JavaVM do not pass through vmoptions
  - JDK-8037825: Fix warnings and enable "warnings as errors" in serviceability native libraries
  - JDK-8042891: Format issues embedded in macros for two g1 source files
  - JDK-8043264: hsdis library not picked up correctly on expected paths
  - JDK-8043646: libosxapp.dylib fails to build on Mac OS 10.9 with clang
  - JDK-8047939: [TESTBUG] Rewrite test/runtime/8001071/Test8001071.sh
  - JDK-8055754: filemap.cpp does not compile with clang
  - JDK-8064909: FragmentMetaspace.java got OutOfMemoryError
  - JDK-8066508: JTReg tests timeout on slow devices when run using JPRT
  - JDK-8066807: langtools/test/Makefile should use -agentvm not -samevm
  - JDK-8071374: -XX:+PrintAssembly -XX:+PrintSignatureHandlers crash fastdebug VM with assert(limit == __null || limit <= nm->code_end()) in RelocIterator::initialize
  - JDK-8073446: TimeZone getOffset API does not return a dst offset between years 2038-2137
  - JDK-8074835: Resolve disabled warnings for libj2gss
  - JDK-8074836: Resolve disabled warnings for libosxkrb5
  - JDK-8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction
  - JDK-8077364: "if( !this )" construct prevents build on Xcode 6.3
  - JDK-8078855: [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in WindowsClassicLookAndFeel
  - JDK-8081764: [TEST_BUG] Test javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on Windows, Solaris Sparcv9 and Linux but passes on MacOSX
  - JDK-8129511: PlatformMidi.c:83 uses malloc without malloc header
  - JDK-8130308: Too low memory usage in TestPromotionFromSurvivorToTenuredAfterMinorGC.java
  - JDK-8130430: [TEST_BUG] remove unnecessary internal calls from javax/swing/JRadioButton/8075609/bug8075609.java
  - JDK-8132148: G1 hs_err region dump legend out of sync with region values
  - JDK-8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on embedded
  - JDK-8134672: [TEST_BUG] Some tests should check isDisplayChangeSupported
  - JDK-8134883: C1 hard crash in range check elimination in Nashorn test262parallel
  - JDK-8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw
  - JDK-8138820: JDK Hotspot build fails with Xcode 7.0.1
  - JDK-8151786: [TESTBUG] java/beans/XMLEncoder/Test4625418.java timed out intermittently
  - JDK-8159898: Negative array size in java/beans/Introspector/Test8027905.java
  - JDK-8166046: [TESTBUG] compiler/stringopts/TestStringObjectInitialization.java fails with OOME
  - JDK-8166724: gc/g1/TestHumongousShrinkHeap.java fails with OOME
  - JDK-8172188: JDI tests fail due to "permission denied" when creating temp file
  - JDK-8177809: File.lastModified() is losing milliseconds (always ends in 000)
  - JDK-8178403: DirectAudio in JavaSound may hang and leak
  - JDK-8180478: tools/launcher/MultipleJRE.sh fails on Windows because of extra-''
  - JDK-8183910: gc/arguments/TestAggressiveHeap.java fails intermittently
  - JDK-8190332: PngReader throws NegativeArraySizeException/OOM error when IHDR width is very large
  - JDK-8190679: java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"
  - JDK-8191955: AArch64: incorrect prefetch distance causes an internal error
  - JDK-8196092: javax/swing/JComboBox/8032878/bug8032878.java fails
  - JDK-8199265: java/util/Arrays/TimSortStackSize2.java fails with OOM
  - JDK-8200550: Xcode 9.3 produce warning -Wexpansion-to-defined
  - JDK-8202299: Java Keystore fails to load PKCS12/PFX certificates created in WindowsServer2016
  - JDK-8203196: C1 emits incorrect code due to integer overflow in _tableswitch keys
  - JDK-8205014: com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java failed with "Read timed out"
  - JDK-8206243: java -XshowSettings fails if memory.limit_in_bytes overflows LONG.max
  - JDK-8206925: Support the certificate_authorities extension
  - JDK-8209996: [PPC64] Fix JFR profiling
  - JDK-8214345: infinite recursion while checking super class
  - JDK-8217230: assert(t == t_no_spec) failure in NodeHash::check_no_speculative_types()
  - JDK-8217348: assert(thread->is_Java_thread()) failed: just checking
  - JDK-8225081: Remove Telia Company CA certificate expiring in April 2021
  - JDK-8225116: Test OwnedWindowsLeak.java intermittently fails
  - JDK-8228757: Fail fast if the handshake type is unknown
  - JDK-8230428: Cleanup dead CastIP node code in formssel.cpp
  - JDK-8231631: sun/net/ftp/FtpURLConnectionLeak.java fails intermittently with NPE
  - JDK-8231841: AArch64: debug.cpp help() is missing an AArch64 line for pns
  - JDK-8231949: [PPC64, s390]: Make async profiling more reliable
  - JDK-8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()
  - JDK-8239053: [8u] clean up undefined-var-template warnings
  - JDK-8239400: [8u] clean up undefined-var-template warnings
  - JDK-8241649: Optimize Character.toString
  - JDK-8241829: Cleanup the code for PrinterJob on windows
  - JDK-8242565: Policy initialization issues when the denyAfter constraint is enabled
  - JDK-8243559: Remove root certificates with 1024-bit keys
  - JDK-8247350: [aarch64] assert(false) failed: wrong size of mach node
  - JDK-8249142: java/awt/FontClass/CreateFont/DeleteFont.sh is unstable
  - JDK-8249278: Revert JDK-8226253 which breaks the spec of AccessibleState.SHOWING for JList
  - JDK-8250876: Fix issues with cross-compile on macos
  - JDK-8252883: AccessDeniedException caused by delayed file deletion on Windows
  - JDK-8253375: OSX build fails with Xcode 12.0 (12A7209)
  - JDK-8254631: Better support ALPN byte wire values in SunJSSE
  - JDK-8255086: Update the root locale display names
  - JDK-8255734: VM should ignore SIGXFSZ on ppc64, s390 too
  - JDK-8256818: SSLSocket that is never bound or connected leaks socket resources
  - JDK-8257039: [8u] GenericTaskQueue destructor is incorrect
  - JDK-8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks
  - JDK-8257884: Re-enable sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test
  - JDK-8257997: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again reports leaks after JDK-8257884
  - JDK-8257999: Parallel GC crash in gc/parallel/TestDynShrinkHeap.java: new region is not in covered_region
  - JDK-8258419: RSA cipher buffer cleanup
  - JDK-8258669: fastdebug jvm crashes when do event based tracing for monitor inflation
  - JDK-8258753: StartTlsResponse.close() hangs due to synchronization issues
  - JDK-8259271: gc/parallel/TestDynShrinkHeap.java still fails "assert(covered_region.contains(new_memregion)) failed: new region is not in covered_region"
  - JDK-8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect
  - JDK-8259886: Improve SSL session cache performance and scalability
  - JDK-8260029: aarch64: fix typo in verify_oop_array
  - JDK-8260236: better init AnnotationCollector _contended_group
  - JDK-8260255: C1: LoopInvariantCodeMotion constructor can leave some fields uninitialized
  - JDK-8260484: CheckExamples.java / NoJavaLangTest.java fail with jtreg 4.2
  - JDK-8260704: ParallelGC: oldgen expansion needs release-store for _end
  - JDK-8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding
  - JDK-8261867: Backport relevant test changes & additions from JDK-8130125
  - JDK-8262110: DST starts from incorrect time in 2038
  - JDK-8262446: DragAndDrop hangs on Windows
  - JDK-8262726: AArch64: C1 StubAssembler::call_RT can corrupt stack
  - JDK-8262730: Enable jdk8u MacOS external debug symbols
  - JDK-8262864: No debug symbols in image for Windows --with-native-debug-symbols=external
  - JDK-8263061: copy wrong unpack200 debuginfo to bin directory after 8252395
  - JDK-8263504: Some OutputMachOpcodes fields are uninitialized
  - JDK-8263600: change rmidRunning to a simple lookup
  - JDK-8264509: jdk8u MacOS zipped debug symbols won't build
  - JDK-8264562: assert(verify_field_bit(1)) failed: Attempting to write an uninitialized event field: type
  - JDK-8264640: CMS ParScanClosure misses a barrier
  - JDK-8264816: Weak handles leak causes GC to take longer
  - JDK-8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod
  - JDK-8265666: Enable AIX build platform to make external debug symbols
  - JDK-8265832: runtime/StackGap/testme.sh fails to compile in 8u
  - JDK-8265988: Fix sun/text/IntHashtable/Bug4170614 for JDK 8u
  - JDK-8266191: Missing aarch64 parts of JDK-8181872 (C1: possible overflow when strength reducing integer multiply by constant)
  - JDK-8266723: JFR periodic events are causing extra allocations
  - JDK-8266929: Unable to use algorithms from 3p providers
  - JDK-8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash
  - JDK-8267426: MonitorVmStartTerminate test timed out on Embedded VM
  - JDK-8267545: [8u] Enable Xcode 12 builds on macOS
  - JDK-8267689: [aarch64] Crash due to bad shift in indirect addressing mode
  - JDK-8268444: keytool -v -list print is incorrect after backport JDK-8141457
  - JDK-8269388: Default build of OpenJDK 8 fails on newer GCCs with warnings as errors on format-overflow
  - JDK-8269468: JDK-8269388 breaks the build on older GCCs
  - JDK-8270533: AArch64: size_fits_all_mem_uses should return false if its output is a CAS

Notes on individual issues:
===========================

security-libs/java.security:

JDK-8256902: Removed Root Certificates with 1024-bit Keys =========================================================
The following root certificates with weak 1024-bit RSA public keys have been removed from the `cacerts` keystore:

Alias Name: thawtepremiumserverca [jdk]
Distinguished Name: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA

Alias Name: verisignclass2g2ca [jdk]
Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

Alias Name: verisignclass3ca [jdk]
Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

Alias Name: verisignclass3g2ca [jdk]
Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

Alias Name: verisigntsaca [jdk]
Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA

JDK-8261361: Removed Telia Company's Sonera Class2 CA certificate =================================================================

The following root certificate have been removed from the cacerts truststore:

Alias Name: soneraclass2ca
Distinguished Name: CN=Sonera Class2 CA, O=Sonera, C=FI

security-libs/javax.net.ssl:

JDK-8257548: Improve Encoding of TLS Application-Layer Protocol Negotiation (ALPN) Values =========================================================================================
Certain TLS ALPN values couldn't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F (7-bit ASCII) into multi-byte arrays that may not be expected by a peer.

ALPN values are now represented using the network byte representation expected by the peer, which should require no modification for standard 7-bit ASCII-based character Strings. However, SunJSSE now encodes/decodes String characters as 8-bit ISO_8859_1/LATIN-1 characters.  This means applications that used characters above
U+000007F that were previously encoded using UTF-8 may need to either
be modified to perform the UTF-8 conversion, or set the Java security property `jdk.tls.alpnCharset` to "UTF-8" revert the behavior.

See the updated guide at
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/alpn.html
for more information.

JDK-8244460: Support for certificate_authorities Extension ==========================================================
The "certificate_authorities" extension is an optional extension introduced in TLS 1.3. It is used to indicate the certificate authorities (CAs) that an endpoint supports and should be used by the receiving endpoint to guide certificate selection.

With this JDK release, the "certificate_authorities" extension is supported for TLS 1.3 in both the client and the server sides.  This extension is always present for client certificate selection, while it is optional for server certificate selection.

Applications can enable this extension for server certificate selection by setting the `jdk.tls.client.enableCAExtension` system property to `true`.  The default value of the property is `false`.

Note that if the client trusts more CAs than the size limit of the extension (less than 2^16 bytes), the extension is not enabled.  Also, some server implementations do not allow handshake messages to exceed
2^14 bytes.  Consequently, there may be interoperability issues when `jdk.tls.client.enableCAExtension` is set to `true` and the client trusts more CAs than the server implementation limit.

Thanks,
--
Andrew :)
Pronouns: he / him or they / them
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

From xiangyuan at tencent.com  Thu Jul 29 13:15:25 2021
From: xiangyuan at tencent.com (=?gb2312?B?eGlhbmd5dWFuKNS2z+gp?=)
Date: Thu, 29 Jul 2021 13:15:25 +0000
Subject: [8u] RFR:  JDK-8271466 Some tests do not support aarch64
Message-ID: <e0b9727d355c463093d45822ad9346d9@tencent.com>

Hi,

I found 3 cases failed on aarch64, and cases are detailed here: https://bugs.openjdk.java.net/browse/JDK-8271466
1. hotspot/test/runtime/StackGap/testme.sh
Error Info: gcc: error: unrecognized command line option '-m64'
When compiling stack-gap, this case passes compiler option '-m64' to gcc, which is unrecoginized by gcc on aarch64.

2. jdk/test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java
Error Info: [jdk/test/sun/management/jmxremote/bootstrap/linux-aarch64/launcher] does not exist. Skipping the test

This testcase depends on a pre-built binary launcher, which is placed the directory "jdk/test/sun/management/jmxremote/bootstrap/{OS-arch}/launcher".
Now there isn't include the file "linux-aarch64/launcher".

3. jdk/test/sun/security/pkcs11/Secmod/TestNssDbSqlite.java
Error Info: Unsupported OS, skipping: Linux-aarch64-64

File jdk/test/sun/security/pkcs11/PKCS11Test.java defines a hashmap named osMap to help to find some native libs on different platform, which doesn't include aarch64.


The fix patch here are:

diff --git a/hotspot/test/runtime/StackGap/testme.sh b/hotspot/test/runtime/StackGap/testme.sh
index 90265e6..5da0867 100644
--- a/hotspot/test/runtime/StackGap/testme.sh
+++ b/hotspot/test/runtime/StackGap/testme.sh
@@ -49,7 +49,10 @@ if [ "x$gcc_cmd" = "x" ]; then
     exit 0;
fi
-CFLAGS="-m${VM_BITS}"
+if [ "x${VM_CPU}" != "xaarch64" ];
+then
+    CFLAGS="-m${VM_BITS}"
+fi
 LD_LIBRARY_PATH=.:${COMPILEJAVA}/jre/lib/${VM_CPU}/${VM_TYPE}:/usr/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
diff --git a/jdk/test/sun/security/pkcs11/PKCS11Test.java b/jdk/test/sun/security/pkcs11/PKCS11Test.java
index 5fc9c60..940d778 100644
--- a/jdk/test/sun/security/pkcs11/PKCS11Test.java
+++ b/jdk/test/sun/security/pkcs11/PKCS11Test.java
@@ -587,6 +587,7 @@ public abstract class PKCS11Test {
         osMap.put("Linux-amd64-64", new String[]{
             "/usr/lib/x86_64-linux-gnu/", "/usr/lib/x86_64-linux-gnu/nss/",
             "/usr/lib64/"});
+        osMap.put("Linux-aarch64-64", new String[]{"/usr/lib64/"});
         osMap.put("Linux-ppc64-64", new String[]{"/usr/lib64/"});
         osMap.put("Linux-ppc64le-64", new String[]{"/usr/lib64/"});
         osMap.put("Windows-x86-32", new String[]{


The attached binary ?launcher? is for case jdk/test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java, and is built with Makefile in jdk/test/sun/management/jmxremote/bootstrap/.
It should be placed ?jdk/test/sun/management/jmxremote/bootstrap/linux-aarch64/?


Looking forward to be reviewed, thanks a lot.

Best wishes
Xiang Yuan



From jdowland at redhat.com  Thu Jul 29 13:29:26 2021
From: jdowland at redhat.com (Jonathan Dowland)
Date: Thu, 29 Jul 2021 14:29:26 +0100
Subject: [8u] RFR: 8244154: Update SunPKCS11 provider with PKCS11 v3.0
 header files
Message-ID: <20210729132926.p7zcw5rwey5tucrn@coil>

Hi there,

Please consider this backport to jdk8u for parity with Oracle 8u291.

The unshuffled 11u patch does not apply cleanly to 8u:

 * License file pkcs11cryptotoken.md does not exist in 8u. pre-Jigsaw
   it's bundled into THIRD_PARTY_README. The below webrev URI includes
   updates to THIRD_PARTY_README for all 8 jdk8u repositories.

 * 11u patch fails to apply 1 out of 52 hunks to pkcs11t.h: this is
   partly due to out-of-order backporting (8265462 brought forward
   one line of changes from this patch). The failed hunk was largely
   (but not entirely) whitespace changes and the introduction of brand
   new code.

   After resolving it by hand, the result is identical to the version of
   the file in jdk11u.

Tests: I ran jdk_tier1 before and after and got the same results
(1135 passed, 196 failed, 10 not run). I'd appreciate any advice on good
tests to run to exercise these changes.

Bug: https://bugs.openjdk.java.net/browse/JDK-8244154
webrev: https://cr.openjdk.java.net/~jdowland/webrevs/JDK-8244154/webrev.00/
zipped webrev: https://cr.openjdk.java.net/~jdowland/webrevs/JDK-8244154/webrev.00.zip


Thanks,

-- 
???? Jonathan Dowland <jdowland at redhat.com>
Senior Software Engineer, OpenJDK, Red Hat


From hohensee at amazon.com  Thu Jul 29 15:55:38 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 29 Jul 2021 15:55:38 +0000
Subject: =?utf-8?B?UmU6IOWbnuWkjTogW0ludGVybmV0XU9wZW5KREsgOHUzMDIgUmVsZWFzZWQ=?=
Message-ID: <66717498-C86B-4355-A0FB-AB928FD89CB3@amazon.com>

8u301 is an Oracle release. The corresponding OpenJDK release is openjdk8u302. The parent issue, https://bugs.openjdk.java.net/browse/JDK-8066588, doesn't show a backport to any OpenJDK 8u release. Feel free to backport!

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of "kalinshi(??)" <kalinshi at tencent.com>
Date: Wednesday, July 28, 2021 at 8:58 PM
To: Andrew Hughes <gnu.andrew at redhat.com>, "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: ??: [Internet]OpenJDK 8u302 Released

Hi,

https://bugs.openjdk.java.net/browse/JDK-8263145 is resolved as fixed in 8u301.

Expect fix is
-            rmid.shutdown(rmidPort);
+            rmid.destroy();

But fix doesn't exist in http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/6ad1494ea3f4/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
This cause test fail after backport https://bugs.openjdk.java.net/browse/JDK-8035000.

Regards
Hui

-----????-----
???: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> ?? Andrew Hughes
????: 2021?7?21? 12:45
???: jdk8u-dev at openjdk.java.net
??: [Internet]OpenJDK 8u302 Released

We are pleased to announce the release of OpenJDK 8u302.

The source tarball is available from:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u302-ga.tar.xz

The tarball is accompanied by a digital signature available at:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u302-ga.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

ab50669afd85086ba451cbc1560ae76e9bc7fc3c9c46e3d37ee5c6a48bb30124  openjdk8u302-ga.tar.xz
6642f62a5eb3c66f4118e4534a0db763f32ba166ea58a4cbb508b48d7d16ce25  openjdk8u302-ga.tar.xz.sig

The checksums can be downloaded from:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u302-ga.sha256

New in release OpenJDK 8u302 (2021-07-20):
===========================================
Live versions of these release notes can be found at:
  * https://bitly.com/openjdk8u302
  * https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u302.txt

* Security fixes
  - JDK-8256157: Improve bytecode assembly
  - JDK-8256491: Better HTTP transport
  - JDK-8258432, CVE-2021-2341: Improve file transfers
  - JDK-8260453: Improve Font Bounding
  - JDK-8260960: Signs of jarsigner signing
  - JDK-8260967, CVE-2021-2369: Better jar file validation
  - JDK-8262380: Enhance XML processing passes
  - JDK-8262403: Enhanced data transfer
  - JDK-8262410: Enhanced rules for zones
  - JDK-8262477: Enhance String Conclusions
  - JDK-8262967: Improve Zip file support
  - JDK-8264066, CVE-2021-2388: Enhance compiler validation
  - JDK-8264079: Improve abstractions
  - JDK-8264460: Improve NTLM support
* Other changes
  - JDK-6878250: (so) IllegalBlockingModeException thrown when reading from a closed SocketChannel's InputStream
  - JDK-6990210: [TEST_BUG] EventDispatchThread/HandleExceptionOnEDT/HandleExceptionOnEDT.java fails on gnome
  - JDK-7059970: Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a file
  - JDK-7106851: Test should not use System.exit
  - JDK-8019470: Changes needed to compile JDK 8 on MacOS with clang compiler
  - JDK-8028618: [TEST BUG] javax/swing/JScrollBar/bug4202954/bug4202954.java fails
  - JDK-8030123: java/beans/Introspector/Test8027648.java fails
  - JDK-8032050: Clean up for java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java
  - JDK-8033289: clang: clean up unused function warning
  - JDK-8034856: gcc warnings compiling src/solaris/native/sun/security/pkcs11
  - JDK-8034857: gcc warnings compiling src/solaris/native/sun/management
  - JDK-8035000: clean up ActivationLibrary.DestroyThread
  - JDK-8035054: JarFacade.c should not include ctype.h
  - JDK-8035287: gcc warnings compiling various libraries files
  - JDK-8036095: RMI tests using testlibrary.RMID and testlibrary.JavaVM do not pass through vmoptions
  - JDK-8037825: Fix warnings and enable "warnings as errors" in serviceability native libraries
  - JDK-8042891: Format issues embedded in macros for two g1 source files
  - JDK-8043264: hsdis library not picked up correctly on expected paths
  - JDK-8043646: libosxapp.dylib fails to build on Mac OS 10.9 with clang
  - JDK-8047939: [TESTBUG] Rewrite test/runtime/8001071/Test8001071.sh
  - JDK-8055754: filemap.cpp does not compile with clang
  - JDK-8064909: FragmentMetaspace.java got OutOfMemoryError
  - JDK-8066508: JTReg tests timeout on slow devices when run using JPRT
  - JDK-8066807: langtools/test/Makefile should use -agentvm not -samevm
  - JDK-8071374: -XX:+PrintAssembly -XX:+PrintSignatureHandlers crash fastdebug VM with assert(limit == __null || limit <= nm->code_end()) in RelocIterator::initialize
  - JDK-8073446: TimeZone getOffset API does not return a dst offset between years 2038-2137
  - JDK-8074835: Resolve disabled warnings for libj2gss
  - JDK-8074836: Resolve disabled warnings for libosxkrb5
  - JDK-8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shrinked by MaxRAMFraction
  - JDK-8077364: "if( !this )" construct prevents build on Xcode 6.3
  - JDK-8078855: [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in WindowsClassicLookAndFeel
  - JDK-8081764: [TEST_BUG] Test javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on Windows, Solaris Sparcv9 and Linux but passes on MacOSX
  - JDK-8129511: PlatformMidi.c:83 uses malloc without malloc header
  - JDK-8130308: Too low memory usage in TestPromotionFromSurvivorToTenuredAfterMinorGC.java
  - JDK-8130430: [TEST_BUG] remove unnecessary internal calls from javax/swing/JRadioButton/8075609/bug8075609.java
  - JDK-8132148: G1 hs_err region dump legend out of sync with region values
  - JDK-8132709: [TESTBUG] gc/g1/TestHumongousShrinkHeap.java might fail on embedded
  - JDK-8134672: [TEST_BUG] Some tests should check isDisplayChangeSupported
  - JDK-8134883: C1 hard crash in range check elimination in Nashorn test262parallel
  - JDK-8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw
  - JDK-8138820: JDK Hotspot build fails with Xcode 7.0.1
  - JDK-8151786: [TESTBUG] java/beans/XMLEncoder/Test4625418.java timed out intermittently
  - JDK-8159898: Negative array size in java/beans/Introspector/Test8027905.java
  - JDK-8166046: [TESTBUG] compiler/stringopts/TestStringObjectInitialization.java fails with OOME
  - JDK-8166724: gc/g1/TestHumongousShrinkHeap.java fails with OOME
  - JDK-8172188: JDI tests fail due to "permission denied" when creating temp file
  - JDK-8177809: File.lastModified() is losing milliseconds (always ends in 000)
  - JDK-8178403: DirectAudio in JavaSound may hang and leak
  - JDK-8180478: tools/launcher/MultipleJRE.sh fails on Windows because of extra-''
  - JDK-8183910: gc/arguments/TestAggressiveHeap.java fails intermittently
  - JDK-8190332: PngReader throws NegativeArraySizeException/OOM error when IHDR width is very large
  - JDK-8190679: java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"
  - JDK-8191955: AArch64: incorrect prefetch distance causes an internal error
  - JDK-8196092: javax/swing/JComboBox/8032878/bug8032878.java fails
  - JDK-8199265: java/util/Arrays/TimSortStackSize2.java fails with OOM
  - JDK-8200550: Xcode 9.3 produce warning -Wexpansion-to-defined
  - JDK-8202299: Java Keystore fails to load PKCS12/PFX certificates created in WindowsServer2016
  - JDK-8203196: C1 emits incorrect code due to integer overflow in _tableswitch keys
  - JDK-8205014: com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java failed with "Read timed out"
  - JDK-8206243: java -XshowSettings fails if memory.limit_in_bytes overflows LONG.max
  - JDK-8206925: Support the certificate_authorities extension
  - JDK-8209996: [PPC64] Fix JFR profiling
  - JDK-8214345: infinite recursion while checking super class
  - JDK-8217230: assert(t == t_no_spec) failure in NodeHash::check_no_speculative_types()
  - JDK-8217348: assert(thread->is_Java_thread()) failed: just checking
  - JDK-8225081: Remove Telia Company CA certificate expiring in April 2021
  - JDK-8225116: Test OwnedWindowsLeak.java intermittently fails
  - JDK-8228757: Fail fast if the handshake type is unknown
  - JDK-8230428: Cleanup dead CastIP node code in formssel.cpp
  - JDK-8231631: sun/net/ftp/FtpURLConnectionLeak.java fails intermittently with NPE
  - JDK-8231841: AArch64: debug.cpp help() is missing an AArch64 line for pns
  - JDK-8231949: [PPC64, s390]: Make async profiling more reliable
  - JDK-8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()
  - JDK-8239053: [8u] clean up undefined-var-template warnings
  - JDK-8239400: [8u] clean up undefined-var-template warnings
  - JDK-8241649: Optimize Character.toString
  - JDK-8241829: Cleanup the code for PrinterJob on windows
  - JDK-8242565: Policy initialization issues when the denyAfter constraint is enabled
  - JDK-8243559: Remove root certificates with 1024-bit keys
  - JDK-8247350: [aarch64] assert(false) failed: wrong size of mach node
  - JDK-8249142: java/awt/FontClass/CreateFont/DeleteFont.sh is unstable
  - JDK-8249278: Revert JDK-8226253 which breaks the spec of AccessibleState.SHOWING for JList
  - JDK-8250876: Fix issues with cross-compile on macos
  - JDK-8252883: AccessDeniedException caused by delayed file deletion on Windows
  - JDK-8253375: OSX build fails with Xcode 12.0 (12A7209)
  - JDK-8254631: Better support ALPN byte wire values in SunJSSE
  - JDK-8255086: Update the root locale display names
  - JDK-8255734: VM should ignore SIGXFSZ on ppc64, s390 too
  - JDK-8256818: SSLSocket that is never bound or connected leaks socket resources
  - JDK-8257039: [8u] GenericTaskQueue destructor is incorrect
  - JDK-8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks
  - JDK-8257884: Re-enable sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test
  - JDK-8257997: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again reports leaks after JDK-8257884
  - JDK-8257999: Parallel GC crash in gc/parallel/TestDynShrinkHeap.java: new region is not in covered_region
  - JDK-8258419: RSA cipher buffer cleanup
  - JDK-8258669: fastdebug jvm crashes when do event based tracing for monitor inflation
  - JDK-8258753: StartTlsResponse.close() hangs due to synchronization issues
  - JDK-8259271: gc/parallel/TestDynShrinkHeap.java still fails "assert(covered_region.contains(new_memregion)) failed: new region is not in covered_region"
  - JDK-8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect
  - JDK-8259886: Improve SSL session cache performance and scalability
  - JDK-8260029: aarch64: fix typo in verify_oop_array
  - JDK-8260236: better init AnnotationCollector _contended_group
  - JDK-8260255: C1: LoopInvariantCodeMotion constructor can leave some fields uninitialized
  - JDK-8260484: CheckExamples.java / NoJavaLangTest.java fail with jtreg 4.2
  - JDK-8260704: ParallelGC: oldgen expansion needs release-store for _end
  - JDK-8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding
  - JDK-8261867: Backport relevant test changes & additions from JDK-8130125
  - JDK-8262110: DST starts from incorrect time in 2038
  - JDK-8262446: DragAndDrop hangs on Windows
  - JDK-8262726: AArch64: C1 StubAssembler::call_RT can corrupt stack
  - JDK-8262730: Enable jdk8u MacOS external debug symbols
  - JDK-8262864: No debug symbols in image for Windows --with-native-debug-symbols=external
  - JDK-8263061: copy wrong unpack200 debuginfo to bin directory after 8252395
  - JDK-8263504: Some OutputMachOpcodes fields are uninitialized
  - JDK-8263600: change rmidRunning to a simple lookup
  - JDK-8264509: jdk8u MacOS zipped debug symbols won't build
  - JDK-8264562: assert(verify_field_bit(1)) failed: Attempting to write an uninitialized event field: type
  - JDK-8264640: CMS ParScanClosure misses a barrier
  - JDK-8264816: Weak handles leak causes GC to take longer
  - JDK-8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod
  - JDK-8265666: Enable AIX build platform to make external debug symbols
  - JDK-8265832: runtime/StackGap/testme.sh fails to compile in 8u
  - JDK-8265988: Fix sun/text/IntHashtable/Bug4170614 for JDK 8u
  - JDK-8266191: Missing aarch64 parts of JDK-8181872 (C1: possible overflow when strength reducing integer multiply by constant)
  - JDK-8266723: JFR periodic events are causing extra allocations
  - JDK-8266929: Unable to use algorithms from 3p providers
  - JDK-8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash
  - JDK-8267426: MonitorVmStartTerminate test timed out on Embedded VM
  - JDK-8267545: [8u] Enable Xcode 12 builds on macOS
  - JDK-8267689: [aarch64] Crash due to bad shift in indirect addressing mode
  - JDK-8268444: keytool -v -list print is incorrect after backport JDK-8141457
  - JDK-8269388: Default build of OpenJDK 8 fails on newer GCCs with warnings as errors on format-overflow
  - JDK-8269468: JDK-8269388 breaks the build on older GCCs
  - JDK-8270533: AArch64: size_fits_all_mem_uses should return false if its output is a CAS

Notes on individual issues:
===========================

security-libs/java.security:

JDK-8256902: Removed Root Certificates with 1024-bit Keys =========================================================
The following root certificates with weak 1024-bit RSA public keys have been removed from the `cacerts` keystore:

Alias Name: thawtepremiumserverca [jdk]
Distinguished Name: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA

Alias Name: verisignclass2g2ca [jdk]
Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

Alias Name: verisignclass3ca [jdk]
Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

Alias Name: verisignclass3g2ca [jdk]
Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

Alias Name: verisigntsaca [jdk]
Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA

JDK-8261361: Removed Telia Company's Sonera Class2 CA certificate =================================================================

The following root certificate have been removed from the cacerts truststore:

Alias Name: soneraclass2ca
Distinguished Name: CN=Sonera Class2 CA, O=Sonera, C=FI

security-libs/javax.net.ssl:

JDK-8257548: Improve Encoding of TLS Application-Layer Protocol Negotiation (ALPN) Values =========================================================================================
Certain TLS ALPN values couldn't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F (7-bit ASCII) into multi-byte arrays that may not be expected by a peer.

ALPN values are now represented using the network byte representation expected by the peer, which should require no modification for standard 7-bit ASCII-based character Strings. However, SunJSSE now encodes/decodes String characters as 8-bit ISO_8859_1/LATIN-1 characters.  This means applications that used characters above
U+000007F that were previously encoded using UTF-8 may need to either
be modified to perform the UTF-8 conversion, or set the Java security property `jdk.tls.alpnCharset` to "UTF-8" revert the behavior.

See the updated guide at
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/alpn.html
for more information.

JDK-8244460: Support for certificate_authorities Extension ==========================================================
The "certificate_authorities" extension is an optional extension introduced in TLS 1.3. It is used to indicate the certificate authorities (CAs) that an endpoint supports and should be used by the receiving endpoint to guide certificate selection.

With this JDK release, the "certificate_authorities" extension is supported for TLS 1.3 in both the client and the server sides.  This extension is always present for client certificate selection, while it is optional for server certificate selection.

Applications can enable this extension for server certificate selection by setting the `jdk.tls.client.enableCAExtension` system property to `true`.  The default value of the property is `false`.

Note that if the client trusts more CAs than the size limit of the extension (less than 2^16 bytes), the extension is not enabled.  Also, some server implementations do not allow handshake messages to exceed
2^14 bytes.  Consequently, there may be interoperability issues when `jdk.tls.client.enableCAExtension` is set to `true` and the client trusts more CAs than the server implementation limit.

Thanks,
--
Andrew :)
Pronouns: he / him or they / them
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


From gnu.andrew at redhat.com  Thu Jul 29 16:04:35 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 29 Jul 2021 17:04:35 +0100
Subject: =?utf-8?B?5Zue5aSN?= =?utf-8?Q?=3A?= [Internet]OpenJDK 8u302
 Released
In-Reply-To: <bd9464eb3bd54eea9c74f15f169ccff8@tencent.com>
References: <20210721044505.GA738682@rincewind>
 <bd9464eb3bd54eea9c74f15f169ccff8@tencent.com>
Message-ID: <20210729160435.GA1636096@rincewind>

On 03:56 Thu 29 Jul     , kalinshi(??) wrote:
> Hi, 
> 
> https://bugs.openjdk.java.net/browse/JDK-8263145 is resolved as fixed in 8u301.
> 
> Expect fix is 
> -            rmid.shutdown(rmidPort);
> +            rmid.destroy();
> 
> But fix doesn't exist in http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/6ad1494ea3f4/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
> This cause test fail after backport https://bugs.openjdk.java.net/browse/JDK-8035000.
> 
> Regards
> Hui
> 

The OpenJDK 8u release is 8u302 and marked as "openjdk8u302" on bugs.openjdk.java.net.

The 8u301 refers to Oracle's private fork, which I agree is confusing.

If you look at:

https://bugs.openjdk.java.net/browse/JDK-8035000

you will see it has both 8u301 (Oracle) and openjdk8u302 (http://hg.openjdk.java.net/jdk8u/jdk8u-dev)

I'll look into getting https://bugs.openjdk.java.net/browse/JDK-8066588 (the parent
bug of 8263145) into 8u for 8u312.

Sorry for the confusion.
Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
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

From gnu.andrew at redhat.com  Thu Jul 29 16:12:38 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 29 Jul 2021 17:12:38 +0100
Subject: [8u] RFR: 8238164: Update Apache Xerces to version 2.12.0
In-Reply-To: <671c0c8b-4a57-01e1-c11e-445b56c963d8@redhat.com>
References: <2b3f0b01-69b6-94ce-e0bd-8863dbdf15e3@redhat.com>
 <20210721171450.GC754562@rincewind>
 <671c0c8b-4a57-01e1-c11e-445b56c963d8@redhat.com>
Message-ID: <20210729161238.GB1636096@rincewind>

On 13:32 Wed 21 Jul     , Elliott Baron wrote:
> Hi Andrew,
> 
> On 2021-07-21 1:14 p.m., Andrew Hughes wrote:
> > On 17:35 Mon 19 Jul     , Elliott Baron wrote:
> > > Hi,
> > > 
> > > I'd like to request a review of 8238164 for 8u for parity with Oracle JDK
> > > 8u261.
> > > 
> > > 8238164 is an 8-only bug, but has an extensive "relates to" list that I used
> > > as a guide for what to backport. I had considered copying over Xerces 2.12.0
> > > en masse from JDK 11, but many of the related changes in 8238164 extend
> > > beyond the Xerces package (e.g. Xalan, XML).
> > > 
> > > The chief concern I have with this backport is the lack of unit tests in the
> > > JAXP repo in 8u. Some of the referenced fixes below include new tests or
> > > changes to tests that were added in JDK 9 beginning with "8043084: XML JAXP
> > > unittest co-location".
> > > 
> > > I'd also like to note that there are minor changes to
> > > javax/xml/stream/XMLEventReader and javax/xml/stream/XMLStreamReader. The
> > > former adds an @Override tag, the other changes are all to documentation.
> > > I'm not sure if the override tag poses a problem to API compatibility.
> > > 
> > > One other minor issue is the @deprecated tag added to Xerces' internal
> > > serializer. This is not public API, but I was unsure whether to change the
> > > version from JDK 1.9 to JDK 1.8. I've just left it alone in this initial
> > > webrev. See:
> > > com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java.
> > > 
> > > The end of this mail contains a detailed list of related fixes mentioned in
> > > 8238164 that are included in this webrev, along with what modifications I
> > > made for them to apply to the 8u tree. The list also covers which of related
> > > fixes are not included in this webrev, and why not.
> > > 
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8238164
> > > Webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8238164/webrev.00/
> > > 
> > > Testing: x86_64 build, jdk_tier1, jdk_other (includes javax/xml) tests
> > > 
> > > Thanks,
> > > Elliott
> > > 
> > > ---
> > 
> > Are you saying this webrev is all (or most of) the fixes you listed merged
> > together?
> > 
> > I don't know how to even begin reviewing such a thing. Can we not just
> > backport the fixes individually, so they can be easily reviewed?
> > 
> 
> Yes, this is an all-in-one webrev. 8238164 led me to believe this was the
> approach taken by Oracle, just based on the information in JBS. The
> individual fixes do not show as being backported to Oracle JDK 8.
> 
> Nevertheless, it's no problem to propose these fixes one at a time. I
> understand it will be easier to review that way.
> 
> Thanks,
> Elliott
> 

Thanks and sorry for the extra work.

I don't know why Oracle merge everything together in one big patch like
this, but it's best to avoid it if possible. Not only is it much harder
to review (it took me about two hours to review the ALPN patch they did
this way) but it also risks not having a record of which bugs have been
resolved by the backport.
-- 
Andrew :)
Pronouns: he / him or they / them
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

From gnu.andrew at redhat.com  Thu Jul 29 16:24:45 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 29 Jul 2021 17:24:45 +0100
Subject: [8u] RFR: 8244154: Update SunPKCS11 provider with PKCS11 v3.0
 header files
In-Reply-To: <20210729132926.p7zcw5rwey5tucrn@coil>
References: <20210729132926.p7zcw5rwey5tucrn@coil>
Message-ID: <20210729162445.GC1636096@rincewind>

On 14:29 Thu 29 Jul     , Jonathan Dowland wrote:
> Hi there,
> 
> Please consider this backport to jdk8u for parity with Oracle 8u291.
> 
> The unshuffled 11u patch does not apply cleanly to 8u:
> 
>  * License file pkcs11cryptotoken.md does not exist in 8u. pre-Jigsaw
>    it's bundled into THIRD_PARTY_README. The below webrev URI includes
>    updates to THIRD_PARTY_README for all 8 jdk8u repositories.
> 
>  * 11u patch fails to apply 1 out of 52 hunks to pkcs11t.h: this is
>    partly due to out-of-order backporting (8265462 brought forward
>    one line of changes from this patch). The failed hunk was largely
>    (but not entirely) whitespace changes and the introduction of brand
>    new code.
> 
>    After resolving it by hand, the result is identical to the version of
>    the file in jdk11u.
> 
> Tests: I ran jdk_tier1 before and after and got the same results
> (1135 passed, 196 failed, 10 not run). I'd appreciate any advice on good
> tests to run to exercise these changes.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8244154
> webrev: https://cr.openjdk.java.net/~jdowland/webrevs/JDK-8244154/webrev.00/
> zipped webrev: https://cr.openjdk.java.net/~jdowland/webrevs/JDK-8244154/webrev.00.zip
> 
> 
> Thanks,
> 
> -- 
> ???? Jonathan Dowland <jdowland at redhat.com>
> Senior Software Engineer, OpenJDK, Red Hat
> 

This looks fine to me. I only looked at the jdk patch; I assume the others are
just the THIRD_PARTY_README hunk applied to the other repos?

If so, please flag for approval.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
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

From gnu.andrew at redhat.com  Thu Jul 29 16:51:37 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 29 Jul 2021 17:51:37 +0100
Subject: [8u] RFR:  JDK-8271466 Some tests do not support aarch64
In-Reply-To: <e0b9727d355c463093d45822ad9346d9@tencent.com>
References: <e0b9727d355c463093d45822ad9346d9@tencent.com>
Message-ID: <20210729165137.GD1636096@rincewind>

On 13:15 Thu 29 Jul     , xiangyuan(??) wrote:
> Hi,
> 
> I found 3 cases failed on aarch64, and cases are detailed here: https://bugs.openjdk.java.net/browse/JDK-8271466
> 1. hotspot/test/runtime/StackGap/testme.sh
> Error Info: gcc: error: unrecognized command line option '-m64'
> When compiling stack-gap, this case passes compiler option '-m64' to gcc, which is unrecoginized by gcc on aarch64.
>

It looks like this issue is unique to 8u and I'm happy for the proposed patch to testme.sh to go into 8u under 8271466.

> 2. jdk/test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java
> Error Info: [jdk/test/sun/management/jmxremote/bootstrap/linux-aarch64/launcher] does not exist. Skipping the test
> 
> This testcase depends on a pre-built binary launcher, which is placed the directory "jdk/test/sun/management/jmxremote/bootstrap/{OS-arch}/launcher".
> Now there isn't include the file "linux-aarch64/launcher".
>

It looks like the solution here is a rewrite:

https://bugs.openjdk.java.net/browse/JDK-8240604

This would need to be backported to 11u first.

> 3. jdk/test/sun/security/pkcs11/Secmod/TestNssDbSqlite.java
> Error Info: Unsupported OS, skipping: Linux-aarch64-64
> 
> File jdk/test/sun/security/pkcs11/PKCS11Test.java defines a hashmap named osMap to help to find some native libs on different platform, which doesn't include aarch64.
>

There is a series of bugs already that fix this and can be backported: JDK-8164322, JDK-8209011 & JDK-8267721
I was already looking at these when I saw JDK-8267721 appear in 11u, so will handle these backports.

Please flag JDK-8271466 with jdk8u-fix-request for approval. Do you need a sponsor to push the StackGap change?

> 
> The fix patch here are:
> 
> diff --git a/hotspot/test/runtime/StackGap/testme.sh b/hotspot/test/runtime/StackGap/testme.sh
> index 90265e6..5da0867 100644
> --- a/hotspot/test/runtime/StackGap/testme.sh
> +++ b/hotspot/test/runtime/StackGap/testme.sh
> @@ -49,7 +49,10 @@ if [ "x$gcc_cmd" = "x" ]; then
>      exit 0;
> fi
> -CFLAGS="-m${VM_BITS}"
> +if [ "x${VM_CPU}" != "xaarch64" ];
> +then
> +    CFLAGS="-m${VM_BITS}"
> +fi
>  LD_LIBRARY_PATH=.:${COMPILEJAVA}/jre/lib/${VM_CPU}/${VM_TYPE}:/usr/lib:$LD_LIBRARY_PATH
> export LD_LIBRARY_PATH

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
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

From jdowland at redhat.com  Thu Jul 29 17:50:11 2021
From: jdowland at redhat.com (Jonathan Dowland)
Date: Thu, 29 Jul 2021 18:50:11 +0100
Subject: RFA: 8080287: The image of BufferedImage.TYPE_INT_ARGB and
 BufferedImage.TYPE_INT_ARGB_PRE is blank
Message-ID: <20210729175011.6vtktwn6e6ghpujl@coil>

Hello,

I'd like to backport the patch from jdk9 for 8080287 to jdk8u:

<https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8b318cc1e0ba>

8080287 is a closed bug, but the patch is open. It applies cleanly to 8u
and introduces a new test. The test fails on 8u before the patch and
passes afterwards.

8080287 is effectively a dependency for JDK-8177393, which applies
cleanly after 8177393, is in Oracle 8u291, and similarly introduces
a new test that fails before the patch and passes after.


Thanks,

-- 
???? Jonathan Dowland <jdowland at redhat.com>
Senior Software Engineer, OpenJDK, Red Hat


From xiangyuan at tencent.com  Fri Jul 30 01:29:53 2021
From: xiangyuan at tencent.com (=?utf-8?B?eGlhbmd5dWFuKOi/nOe/lCk=?=)
Date: Fri, 30 Jul 2021 01:29:53 +0000
Subject: Reply: [Internet]Re: [8u] RFR: JDK-8271466 Some tests do not support
 aarch64
Message-ID: <619d3913cfa14fea9c06d025e5e56496@tencent.com>

Hi,
Thanks a lot for reviewing.

> Please flag JDK-8271466 with jdk8u-fix-request for approval.
The label has been added. 

> Do you need a sponsor to push the StackGap change?
Yes, thank you very much.

Best wishes!
Xiang Yuan

---------------
Addresser: Andrew Hughes <gnu.andrew at redhat.com> 
Date: 2021-07-30 0:52
Addressee: xiangyuan <xiangyuan at tencent.com>
Copy to: jdk8u-dev at openjdk.java.net
Subject: [Internet]Re: [8u] RFR: JDK-8271466 Some tests do not support aarch64

On 13:15 Thu 29 Jul     , xiangyuan wrote:
> Hi,
> 
> I found 3 cases failed on aarch64, and cases are detailed here: 
> https://bugs.openjdk.java.net/browse/JDK-8271466
> 1. hotspot/test/runtime/StackGap/testme.sh
> Error Info: gcc: error: unrecognized command line option '-m64'
> When compiling stack-gap, this case passes compiler option '-m64' to gcc, which is unrecoginized by gcc on aarch64.
>

It looks like this issue is unique to 8u and I'm happy for the proposed patch to testme.sh to go into 8u under 8271466.

> 2. jdk/test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java
> Error Info: 
> [jdk/test/sun/management/jmxremote/bootstrap/linux-aarch64/launcher] 
> does not exist. Skipping the test
> 
> This testcase depends on a pre-built binary launcher, which is placed the directory "jdk/test/sun/management/jmxremote/bootstrap/{OS-arch}/launcher".
> Now there isn't include the file "linux-aarch64/launcher".
>

It looks like the solution here is a rewrite:

https://bugs.openjdk.java.net/browse/JDK-8240604

This would need to be backported to 11u first.

> 3. jdk/test/sun/security/pkcs11/Secmod/TestNssDbSqlite.java
> Error Info: Unsupported OS, skipping: Linux-aarch64-64
> 
> File jdk/test/sun/security/pkcs11/PKCS11Test.java defines a hashmap named osMap to help to find some native libs on different platform, which doesn't include aarch64.
>

There is a series of bugs already that fix this and can be backported: JDK-8164322, JDK-8209011 & JDK-8267721 I was already looking at these when I saw JDK-8267721 appear in 11u, so will handle these backports.

Please flag JDK-8271466 with jdk8u-fix-request for approval. Do you need a sponsor to push the StackGap change?

> 
> The fix patch here are:
> 
> diff --git a/hotspot/test/runtime/StackGap/testme.sh 
> b/hotspot/test/runtime/StackGap/testme.sh
> index 90265e6..5da0867 100644
> --- a/hotspot/test/runtime/StackGap/testme.sh
> +++ b/hotspot/test/runtime/StackGap/testme.sh
> @@ -49,7 +49,10 @@ if [ "x$gcc_cmd" = "x" ]; then
>      exit 0;
> fi
> -CFLAGS="-m${VM_BITS}"
> +if [ "x${VM_CPU}" != "xaarch64" ];
> +then
> +    CFLAGS="-m${VM_BITS}"
> +fi
>  
> LD_LIBRARY_PATH=.:${COMPILEJAVA}/jre/lib/${VM_CPU}/${VM_TYPE}:/usr/lib
> :$LD_LIBRARY_PATH
> export LD_LIBRARY_PATH

Thanks,
--
Andrew :)
Pronouns: he / him or they / them
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

From kalinshi at tencent.com  Fri Jul 30 02:02:26 2021
From: kalinshi at tencent.com (=?utf-8?B?a2FsaW5zaGko5pa95oWnKQ==?=)
Date: Fri, 30 Jul 2021 02:02:26 +0000
Subject: =?utf-8?B?5Zue5aSNOiBbSW50ZXJuZXRdUmU6ICDlm57lpI06IE9wZW5KREsgOHUzMDIg?=
 =?utf-8?Q?Released?=
In-Reply-To: <20210729160435.GA1636096@rincewind>
References: <20210721044505.GA738682@rincewind>
 <bd9464eb3bd54eea9c74f15f169ccff8@tencent.com>
 <20210729160435.GA1636096@rincewind>
Message-ID: <751c951c43114b2aa09817c1ff5e5c0f@tencent.com>

Thanks for your clarification!

Regards
Hui

-----????-----
???: Andrew Hughes <gnu.andrew at redhat.com> 
????: 2021?7?30? 0:05
???: kalinshi(??) <kalinshi at tencent.com>
??: jdk8u-dev at openjdk.java.net
??: [Internet]Re: ??: OpenJDK 8u302 Released

On 03:56 Thu 29 Jul     , kalinshi(??) wrote:
> Hi,
> 
> https://bugs.openjdk.java.net/browse/JDK-8263145 is resolved as fixed in 8u301.
> 
> Expect fix is 
> -            rmid.shutdown(rmidPort);
> +            rmid.destroy();
> 
> But fix doesn't exist in 
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/6ad1494ea3f4/test/
> javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
> This cause test fail after backport https://bugs.openjdk.java.net/browse/JDK-8035000.
> 
> Regards
> Hui
> 

The OpenJDK 8u release is 8u302 and marked as "openjdk8u302" on bugs.openjdk.java.net.

The 8u301 refers to Oracle's private fork, which I agree is confusing.

If you look at:

https://bugs.openjdk.java.net/browse/JDK-8035000

you will see it has both 8u301 (Oracle) and openjdk8u302 (http://hg.openjdk.java.net/jdk8u/jdk8u-dev)

I'll look into getting https://bugs.openjdk.java.net/browse/JDK-8066588 (the parent bug of 8263145) into 8u for 8u312.

Sorry for the confusion.
Thanks,
--
Andrew :)
Pronouns: he / him or they / them
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

From zgu at redhat.com  Fri Jul 30 14:31:24 2021
From: zgu at redhat.com (Zhengyu Gu)
Date: Fri, 30 Jul 2021 10:31:24 -0400
Subject: [8u] RFR 8065895: Synchronous signals during error reporting may
 terminate or hang VM process
Message-ID: <7f9f7fb2-fe32-c720-9439-481c86c224a6@redhat.com>

I would like to backport this patch to openjdk8u for parity with Oracle 
8u321.

Bug: https://bugs.openjdk.java.net/browse/JDK-8065895
jdk9 patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6bfc40057b3f


jdk9 patch does not apply cleanly. There is only one conflict in 
debug.cpp, due to line shifts.

8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8065895-8u/webrev.00/


Thanks,

-Zhengyu


From thomas.stuefe at gmail.com  Fri Jul 30 16:53:16 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 30 Jul 2021 18:53:16 +0200
Subject: [8u] RFR 8065895: Synchronous signals during error reporting may
 terminate or hang VM process
In-Reply-To: <7f9f7fb2-fe32-c720-9439-481c86c224a6@redhat.com>
References: <7f9f7fb2-fe32-c720-9439-481c86c224a6@redhat.com>
Message-ID: <CAA-vtUwaC-vNoWGsQFJdBuXhfP1cVrggAkWtBJF5qRvrCLHtDw@mail.gmail.com>

Looks good to me, but I am not a Reviewer for jdk8u.

Note that there was a mixup with the original patch and the regression
tests got lost and pushed later with a separate RFE (JDK-8072575).

Cheers, Thomas

On Fri, Jul 30, 2021 at 4:32 PM Zhengyu Gu <zgu at redhat.com> wrote:

> I would like to backport this patch to openjdk8u for parity with Oracle
> 8u321.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8065895
> jdk9 patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6bfc40057b3f
>
>
> jdk9 patch does not apply cleanly. There is only one conflict in
> debug.cpp, due to line shifts.
>
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8065895-8u/webrev.00/
>
>
> Thanks,
>
> -Zhengyu
>
>

From gnu.andrew at redhat.com  Fri Jul 30 19:45:58 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 30 Jul 2021 20:45:58 +0100
Subject: RFA: 8080287: The image of BufferedImage.TYPE_INT_ARGB and
 BufferedImage.TYPE_INT_ARGB_PRE is blank
In-Reply-To: <20210729175011.6vtktwn6e6ghpujl@coil>
References: <20210729175011.6vtktwn6e6ghpujl@coil>
Message-ID: <20210730194558.GA1735170@rincewind>

On 18:50 Thu 29 Jul     , Jonathan Dowland wrote:
> Hello,
> 
> I'd like to backport the patch from jdk9 for 8080287 to jdk8u:
> 
> <https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8b318cc1e0ba>
> 
> 8080287 is a closed bug, but the patch is open. It applies cleanly to 8u
> and introduces a new test. The test fails on 8u before the patch and
> passes afterwards.
> 
> 8080287 is effectively a dependency for JDK-8177393, which applies
> cleanly after 8177393, is in Oracle 8u291, and similarly introduces
> a new test that fails before the patch and passes after.
> 
> 
> Thanks,
> 
> -- 
> ???? Jonathan Dowland <jdowland at redhat.com>
> Senior Software Engineer, OpenJDK, Red Hat
> 

Approved. Thanks.
-- 
Andrew :)
Pronouns: he / him or they / them
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

From quantum6 at yeah.net  Sat Jul  3 00:05:59 2021
From: quantum6 at yeah.net (=?UTF-8?B?5p+z6bKy6bmP?=)
Date: Sat, 03 Jul 2021 00:05:59 -0000
Subject: libX11-dev doesn't exist, should replace with libx11-dev
In-Reply-To: <98003969-f47a-25ed-343c-d46814a3f975@redhat.com>
References: <76b39ac4.17b1.17a5d289df8.Coremail.quantum6@yeah.net>
 <98003969-f47a-25ed-343c-d46814a3f975@redhat.com>
Message-ID: <53de91f5.8c.17a69af5c50.Coremail.quantum6@yeah.net>

My OS is 
Linux nanjing 5.3.0-28-generic #30~18.04.1-Ubuntu SMP Fri Jan 17 06:14:09 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux


1, run command: configure
configure: error: Could not find all X11 headers (shape.h Xrender.h XTest.h Intrinsic.h). You might be able to fix this by running 'sudo apt-get install libX11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev'.


2, run command: sudo apt-get install libX11-dev

E: Unable to locate package libX11-dev




3, run command: sudo apt-get install libx11-dev

libx11-dev is already the newest version (2:1.6.4-3ubuntu0.4).



File: common/autoconf/generated-configure.sh
about 3881 line, we should modify libX11-dev To libx11-dev


Here is hg diff:
diff -r f7f1e6a9ee97 common/autoconf/help.m4
--- a/common/autoconf/help.m4   Mon Jun 28 19:48:48 2021 +0100
+++ b/common/autoconf/help.m4   Sat Jul 03 08:04:47 2021 +0800
@@ -112,7 +112,7 @@
     pulse)
       PKGHANDLER_COMMAND="sudo apt-get install libpulse-dev" ;;
     x11)
-      PKGHANDLER_COMMAND="sudo apt-get install libX11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev" ;;
+      PKGHANDLER_COMMAND="sudo apt-get install libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev" ;;
     ccache)
       PKGHANDLER_COMMAND="sudo apt-get install ccache" ;;
   esac


Thanks,.
Liu Kunpeng

From quantum6 at yeah.net  Sun Jul 25 09:20:21 2021
From: quantum6 at yeah.net (=?UTF-8?B?5p+z6bKy6bmP?=)
Date: Sun, 25 Jul 2021 17:20:21 +0800 (CST)
Subject: I build openjdk on windows and visual studo(all chinese version), a
 error ocurred.
In-Reply-To: <53de91f5.8c.17a69af5c50.Coremail.quantum6@yeah.net>
References: <76b39ac4.17b1.17a5d289df8.Coremail.quantum6@yeah.net>
 <98003969-f47a-25ed-343c-d46814a3f975@redhat.com>
 <53de91f5.8c.17a69af5c50.Coremail.quantum6@yeah.net>
Message-ID: <5f0cf6c4.461.17adcf72058.Coremail.quantum6@yeah.net>

Enviroment: Windows 7 chinese version, Visual studio 2010 chinese version.


The error is:
D:\openjdk8\hotspot/make/windows/get_msc_ver.sh: line 65: [: ?? x64 ? Microsoft (R) C/C++ ????? 16: integer expression expected
/usr/bin/expr: syntax error
NMAKE : fatal error U1077: ?sh?: ?????0x2?
Stop.
make[3]: *** [Makefile:231: generic_build2] Error 2
make[2]: *** [Makefile:177: product] Error 2
make[1]: *** [HotspotWrapper.gmk:45: /cygdrive/d/openjdk8/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2
make: *** [/cygdrive/d/openjdk8/make/Main.gmk:110: hotspot-only] Error 2



Fix(Maye be there is better code):

hotspot\make\windows\get_msc_ver.sh
from line number 58, like this:
if [ "x$FORCE_MSC_VER" != "x" ]; then
  echo "MSC_VER=$FORCE_MSC_VER"
else
  MSC_VER_RAW=`cl 2>&1 | "$HEAD" -n 1 | "$SED" 's/.*Version[\ ]*\([0-9][0-9.]*\).*/\1/'`
  # on win7 and vs2010 chinese version, the result is:?? 80x86 ? Microsoft (R) 32 ? C/C++ ????? 16.00.30319.01 ?
  # CHINESE_TEXT="?????"
  CHINESE_TEXT="C/C++"
  if [[ ${MSC_VER_RAW} == *${CHINESE_TEXT}* ]]; then
    MSC_VER_RAW=`echo ${MSC_VER_RAW} | awk '{ print $8 }'`
  fi
  # MSC_VER_RAW=16.00.303109.01


Many thank and best regards


Liu Kunpeng.

From vipulmehta.1989 at gmail.com  Fri Jul 30 10:04:51 2021
From: vipulmehta.1989 at gmail.com (Vipul Mehta)
Date: Fri, 30 Jul 2021 15:34:51 +0530
Subject: OpenJDK 8u302 - Kerberos - Allow non-forwardable S4U2Self ticket
Message-ID: <CAMeQEL-oyBaJ3FtiKzOxf1WhbdUV4N8K39PayRj4n+n6UNEEVQ@mail.gmail.com>

Hi,

Resource based constrained delegation support was added to JDK via
following fix: https://bugs.openjdk.java.net/browse/JDK-8005819

This change does not allow S4U2Self ticket issued by KDC to be
non-forwardable, as
sun.security.krb5.internal.CredentialsUtil -> acquireS4U2selfCreds() ->
line 105 throws exception.

Resource based constrained delegation S4U2Proxy will work even without a
non forwardable S4U2Self ticket if KDC is configured to accept such a
ticket. So, Java should let KDC decide whether to accept or reject such a
ticket.

S4U2Self ticket will be marked as forwardable by microsoft KDC in following
cases:
1) trustedToAuthForDelegation is true
2) trustedToAuthForDelegation is false and msDs-AllowedToDelegateTo list is
empty.

If trustedToAuthForDelegation is false and msDs-AllowedToDelegateTo list is
non-empty then S4U2Self ticket will not have a forwardable flag.

The S4U2Self ticket is used in S4U2Proxy TGS-Request.
If S4U2Self ticket is not forwardable then S4U2Proxy will work in following
cases of single realm resource based constrained delegation:

1) Patch for CVE-2020-16996 is not applied in KDC.
2) Patch for CVE-2020-16996 is applied in KDC and registry entry -
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Kdc\NonForwardableDelegation
is set to 1. (DWORD type)
-- 
Regards,
Vipul

From quantum6 at yeah.net  Fri Jul 30 23:30:06 2021
From: quantum6 at yeah.net (=?UTF-8?B?5p+z6bKy6bmP?=)
Date: Sat, 31 Jul 2021 07:30:06 +0800 (CST)
Subject: I build openjdk on windows and visual studo(all chinese version), a
 error ocurred(with hg diff)
In-Reply-To: <5f0cf6c4.461.17adcf72058.Coremail.quantum6@yeah.net>
References: <76b39ac4.17b1.17a5d289df8.Coremail.quantum6@yeah.net>
 <98003969-f47a-25ed-343c-d46814a3f975@redhat.com>
 <53de91f5.8c.17a69af5c50.Coremail.quantum6@yeah.net>
 <5f0cf6c4.461.17adcf72058.Coremail.quantum6@yeah.net>
Message-ID: <43e97ff5.4b.17af9c0e780.Coremail.quantum6@yeah.net>

Enviroment: Windows 7 chinese version, Visual studio 2010 chinese version.



The error is:
D:\openjdk8\hotspot/make/windows/get_msc_ver.sh: line 65: [: ?? x64 ? Microsoft (R) C/C++ ????? 16: integer expression expected
/usr/bin/expr: syntax error
NMAKE : fatal error U1077: ?sh?: ?????0x2?
Stop.
make[3]: *** [Makefile:231: generic_build2] Error 2
make[2]: *** [Makefile:177: product] Error 2
make[1]: *** [HotspotWrapper.gmk:45: /cygdrive/d/openjdk8/build/windows-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2
make: *** [/cygdrive/d/openjdk8/make/Main.gmk:110: hotspot-only] Error 2



Fix(Maye be there is better code):

quantum6 at taishan:~/jdk8u/hotspot/make/windows$ hg diff
diff -r 91924b4ea982 make/windows/get_msc_ver.sh
--- a/make/windows/get_msc_ver.sh       Tue Jul 20 18:10:23 2021 +0100
+++ b/make/windows/get_msc_ver.sh       Sat Jul 31 07:29:36 2021 +0800
@@ -59,6 +59,8 @@
   echo "MSC_VER=$FORCE_MSC_VER"
 else
   MSC_VER_RAW=`cl 2>&1 | "$HEAD" -n 1 | "$SED" 's/.*Version[\ ]*\([0-9][0-9.]*\).*/\1/'`
+  MSC_VER_RAW=`cl 2>&1 | "$HEAD" -n 1 | "$SED" 's/.*???[\ ]*\([0-9][0-9.]*\).*/\1/'`
+  # MSC_VER_RAW=16.00.303109.01
   MSC_VER_MAJOR=`"$ECHO" $MSC_VER_RAW | "$CUT" -d'.' -f1`
   MSC_VER_MINOR=`"$ECHO" $MSC_VER_RAW | "$CUT" -d'.' -f2`
   MSC_VER_MICRO=`"$ECHO" $MSC_VER_RAW | "$CUT" -d'.' -f3`






Many thank and best regards


Liu Kunpeng.