From Alan.Bateman at oracle.com  Fri Aug  2 15:08:29 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 2 Aug 2019 08:08:29 -0700
Subject: RFR: JDK-8058539: Platform specific source files may not end up
 in src.zip
In-Reply-To: <6d3aec6e-cb92-55e4-f26d-1572ec41b03a@oracle.com>
References: <6d3aec6e-cb92-55e4-f26d-1572ec41b03a@oracle.com>
Message-ID: <f692dc50-eeb0-0c1d-bd0c-9f8894079736@oracle.com>

On 20/06/2019 10:39, Erik Joelsson wrote:
> For both java and native source files, we have a feature in the build 
> which allows overriding based on file name for more specific version 
> (i.e. OS specific overrides shared). This works quite well and is used 
> in several locations. It does however break down when building 
> src.zip. The file with the newest modification date gets picked by the 
> zip utility, which essentially makes it random. Luckily the kind of 
> files that are overridden this way are usually rather fringe so very 
> few people probably care. Even so, the build should be correct, so 
> here is a patch that fixes it.
>
> I've added a loop that looks for duplicate files in the given source 
> roots and adds any but the first found to exclude lists. I was afraid 
> this would add noticeable time to incremental rebuilds, but I found a 
> way to work around this by putting this calculation in the recipe for 
> the zip file. The drawback is that we cannot remove these files from 
> the prerequisites list, so we may trigger unnecessary rebuilds of zip 
> files. However, since the number of src files that are handled this 
> way is so small, I believe that to be a very rare situation and that 
> it's much more valuable to avoid doing the calculation most of the 
> time instead. (On my machine, without this hack, incremental rebuild 
> of "make zip-source" went from 2.7s to 3.2s, which is noticeable 
> enough IMO, with the hack, there is no difference.)
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8058539
>
> Webrev: http://cr.openjdk.java.net/~erikj/8058539/webrev.01/
This looks okay to me.

-Alan


From javalists at cbfiddle.com  Tue Aug  6 16:45:48 2019
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 6 Aug 2019 09:45:48 -0700
Subject: make reconfigure status
Message-ID: <FABCC480-3102-4BE5-9E45-A11F7B6F50C5@cbfiddle.com>

In case this is useful...

I don?t know what the status is of ?make reconfigure?, but I suspect it is unsupported because I see no mention of it in the build doc.

However:

* It still exists

* It is mentioned in the output of make

* It failed when I tried to use it (on macOS 10.15.5)

The error has something to do with choosing a configuration output directory. Somehow it winds up connected to my home directory and then complains about it.

I had no trouble running ?bash configure?.


Please rerun configure! Easiest way to do this is by running
'make reconfigure'.


checking where to store configuration... in current directory
configure: Current directory is /Users/alan.
configure: Since this is not the source root, configure will output the configuration here
configure: (as opposed to creating a configuration in <src_root>/build/<conf-name>).
configure: However, this directory is not empty. This is not allowed, since it could
configure: seriously mess up just about everything.
configure: Try 'cd /Volumes/A/JDK/client2' and restart configure
configure: (or create a new empty directory and cd to it).
configure: error: Will not continue creating configuration in /Users/alan
/Users/alan/configure-support/generated-configure.sh: line 82: 5: Bad file descriptor
configure exiting with result code 1
make[1]: *** [reconfigure] Error 1
make: *** [reconfigure] Error 2



From jonathan.gibbons at oracle.com  Tue Aug  6 16:50:33 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 6 Aug 2019 09:50:33 -0700
Subject: make reconfigure status
In-Reply-To: <FABCC480-3102-4BE5-9E45-A11F7B6F50C5@cbfiddle.com>
References: <FABCC480-3102-4BE5-9E45-A11F7B6F50C5@cbfiddle.com>
Message-ID: <337e3573-fa5b-be91-e5fe-027b6d3b414d@oracle.com>

Alan,

There was a recent change to the build such that you need to do a 
one-time delete of your build directory, and run configure again. After 
that, "make reconfigure" works as expected.

-- Jon

On 8/6/19 9:45 AM, Alan Snyder wrote:
> In case this is useful...
>
> I don?t know what the status is of ?make reconfigure?, but I suspect it is unsupported because I see no mention of it in the build doc.
>
> However:
>
> * It still exists
>
> * It is mentioned in the output of make
>
> * It failed when I tried to use it (on macOS 10.15.5)
>
> The error has something to do with choosing a configuration output directory. Somehow it winds up connected to my home directory and then complains about it.
>
> I had no trouble running ?bash configure?.
>
>
> Please rerun configure! Easiest way to do this is by running
> 'make reconfigure'.
>
>
> checking where to store configuration... in current directory
> configure: Current directory is /Users/alan.
> configure: Since this is not the source root, configure will output the configuration here
> configure: (as opposed to creating a configuration in <src_root>/build/<conf-name>).
> configure: However, this directory is not empty. This is not allowed, since it could
> configure: seriously mess up just about everything.
> configure: Try 'cd /Volumes/A/JDK/client2' and restart configure
> configure: (or create a new empty directory and cd to it).
> configure: error: Will not continue creating configuration in /Users/alan
> /Users/alan/configure-support/generated-configure.sh: line 82: 5: Bad file descriptor
> configure exiting with result code 1
> make[1]: *** [reconfigure] Error 1
> make: *** [reconfigure] Error 2
>


From javalists at cbfiddle.com  Tue Aug  6 19:42:22 2019
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 6 Aug 2019 12:42:22 -0700
Subject: nasgen build error
Message-ID: <23FD814F-BA81-4C12-B6FB-7C8FFA6550EC@cbfiddle.com>

Any ideas on what this means?

Running nasgen
Error occurred during initialization of boot layer
java.lang.BootstrapMethodError: bootstrap method initialization exception
Caused by: java.lang.IllegalArgumentException
make[3]: *** [/Volumes/A/JDK/client/build/macosx-x86_64-server-release/jdk/modules/jdk.scripting.nashorn/_the.nasgen.run] Error 1
make[2]: *** [jdk.scripting.nashorn-java] Error 2



From bummer at gmx.net  Sat Aug 10 23:42:20 2019
From: bummer at gmx.net (Ralf H)
Date: Sun, 11 Aug 2019 01:42:20 +0200
Subject: windows build with non-english toolchain installation
Message-ID: <9631de32-9925-df96-1625-20046a90a3b8@gmx.net>

Hallihallo,

when building on windows systems with non-english toolchains (in my
case, German), there are usually non-english COMPILER_VERSION_OUTPUTs to
be checked in make/autoconf/toolchain.m4.

Line 462 reads

    $ECHO "$COMPILER_VERSION_OUTPUT" | $GREP "Microsoft.*Compiler" >
/dev/null

but my german version reports as "Microsoft (R)
C/C++-Optimierungscompiler Version 19.15.26732.1 f?r x64"

meaning the capital C in the GREP search should be either omitted or the
GREP made case-insensitive

Not sure if this covers *all* languages :)


From chris.hegarty at oracle.com  Fri Aug 16 17:32:23 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 16 Aug 2019 18:32:23 +0100
Subject: RFR [14] 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't
 find dependent libraries
In-Reply-To: <921e69d2-10dd-14d9-0202-6a01401d713d@oracle.com>
References: <1E47355B-7AFA-431F-BDB6-3A6632C92D80@oracle.com>
 <921e69d2-10dd-14d9-0202-6a01401d713d@oracle.com>
Message-ID: <6DD848EC-89B0-4362-B2A0-CDA493DB6EF6@oracle.com>

Adding build-dev; minor change to remove a linker dependency.

-Chris.

> On 16 Aug 2019, at 18:22, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi chris,
> 
> That looks good to me - although don't count me as reviewer
> for the makefile changes.
> 
> best regards,
> 
> -- daniel
> 
> On 16/08/2019 18:05, Chris Hegarty wrote:
>> An unfortunate eager dependency on urlmon.dll has crept into net.dll,
>> the JIRA issue contains more details [1].
>> The dependency should be made lazy and optional, since if only pertains
>> to NTLM authentication over HTTP.
>> Webrev:
>>   https://cr.openjdk.java.net/~chegar/8225425/webrev.01/
>> -Chris.
>> [1] https://bugs.openjdk.java.net/browse/JDK-8225425
> 



From erik.joelsson at oracle.com  Fri Aug 16 17:57:26 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 16 Aug 2019 10:57:26 -0700
Subject: RFR [14] 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't
 find dependent libraries
In-Reply-To: <6DD848EC-89B0-4362-B2A0-CDA493DB6EF6@oracle.com>
References: <1E47355B-7AFA-431F-BDB6-3A6632C92D80@oracle.com>
 <921e69d2-10dd-14d9-0202-6a01401d713d@oracle.com>
 <6DD848EC-89B0-4362-B2A0-CDA493DB6EF6@oracle.com>
Message-ID: <3be1e526-4e0a-7e1c-31fe-713ee2528299@oracle.com>

Build change looks good.

/Erik

On 2019-08-16 10:32, Chris Hegarty wrote:
> Adding build-dev; minor change to remove a linker dependency.
>
> -Chris.
>
>> On 16 Aug 2019, at 18:22, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi chris,
>>
>> That looks good to me - although don't count me as reviewer
>> for the makefile changes.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 16/08/2019 18:05, Chris Hegarty wrote:
>>> An unfortunate eager dependency on urlmon.dll has crept into net.dll,
>>> the JIRA issue contains more details [1].
>>> The dependency should be made lazy and optional, since if only pertains
>>> to NTLM authentication over HTTP.
>>> Webrev:
>>>    https://cr.openjdk.java.net/~chegar/8225425/webrev.01/
>>> -Chris.
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8225425


From gnu.andrew at redhat.com  Wed Aug 21 19:33:32 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 21 Aug 2019 20:33:32 +0100
Subject: RFR: [8u] 8141570: Fix Zero interpreter build for
 --disable-precompiled-headers
Message-ID: <db4bf4b5-2263-ef35-210a-3049f1e9dfbe@redhat.com>

This is the first of a series of four changes to support -Wreturn-type
in OpenJDK 8u. The -Wreturn-type warning catches instances where control
flow exits a non-void function without returning a value. This can
combine with compiler optimisations in some cases to cause runtime
crashes. The warning is turned on by default in GCC 8 [0], causing the
build to fail if it is not explicitly disabled.

The subsequent changes are JDK-8062808 to apply the warning and fix
issues in the default build, JDK-8143245 to fix issues in the Zero build
and JDK-8197981 to fix one remaining Zero issue on 32-bit platforms only.

This change ensures the Zero build is not broken by 8062808 by disabling
-Wreturn-type in the Zero makefile.

Changes in the backport process:

* The G1 changes are dropped as 8u does not contain JDK-8073013, which
introduces g1EvacStats.*
* I've changed the ifeq ($(USE_CLANG), true) to ifeq
($(JVM_VARIANT_ZEROSHARK), true). There seems to have been a mistake in
the original patch which equated LLVM with clang. What is actually
referred to by "some version of llvm do not like -Wundef" is the LLVM
headers that Shark is built against, not the clang compiler which also
uses LLVM. This made its way through to the new HotSpot build in OpenJDK
9 & 10, but is gone as of JDK-8198724 in OpenJDK 11 and later.

This backport has been in IcedTea since 3.8.0 (2018-05-29) [1] and our
RHEL RPMs since 2018-06-16 without issue. Builds of current 8u-dev on
x86_64 with Zero release and Zero slowdebug succeeded.

[0] https://gcc.gnu.org/gcc-8/changes.html
[1] https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3548
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew



From sgehwolf at redhat.com  Thu Aug 22 08:52:38 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 22 Aug 2019 10:52:38 +0200
Subject: RFR: [8u] 8141570: Fix Zero interpreter build for
 --disable-precompiled-headers
In-Reply-To: <db4bf4b5-2263-ef35-210a-3049f1e9dfbe@redhat.com>
References: <db4bf4b5-2263-ef35-210a-3049f1e9dfbe@redhat.com>
Message-ID: <5935ba25ce64cfc747e9717ca1a742d7f35c0ec7.camel@redhat.com>

Hi Andrew,

On Wed, 2019-08-21 at 20:33 +0100, Andrew John Hughes wrote:
> This is the first of a series of four changes to support -Wreturn-type
> in OpenJDK 8u. The -Wreturn-type warning catches instances where control
> flow exits a non-void function without returning a value. This can
> combine with compiler optimisations in some cases to cause runtime
> crashes. The warning is turned on by default in GCC 8 [0], causing the
> build to fail if it is not explicitly disabled.
> 
> The subsequent changes are JDK-8062808 to apply the warning and fix
> issues in the default build, JDK-8143245 to fix issues in the Zero build
> and JDK-8197981 to fix one remaining Zero issue on 32-bit platforms only.
> 
> This change ensures the Zero build is not broken by 8062808 by disabling
> -Wreturn-type in the Zero makefile.
> 
> Changes in the backport process:
> 
> * The G1 changes are dropped as 8u does not contain JDK-8073013, which
> introduces g1EvacStats.*
> * I've changed the ifeq ($(USE_CLANG), true) to ifeq
> ($(JVM_VARIANT_ZEROSHARK), true). There seems to have been a mistake in
> the original patch which equated LLVM with clang. What is actually
> referred to by "some version of llvm do not like -Wundef" is the LLVM
> headers that Shark is built against, not the clang compiler which also
> uses LLVM. This made its way through to the new HotSpot build in OpenJDK
> 9 & 10, but is gone as of JDK-8198724 in OpenJDK 11 and later.
> 
> This backport has been in IcedTea since 3.8.0 (2018-05-29) [1] and our
> RHEL RPMs since 2018-06-16 without issue. Builds of current 8u-dev on
> x86_64 with Zero release and Zero slowdebug succeeded.
> 
> [0] https://gcc.gnu.org/gcc-8/changes.html
> [1] https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3548

I don't see any webrev. Did you forget to link to it?

Thanks,
Severin



From gnu.andrew at redhat.com  Thu Aug 22 09:15:54 2019
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 22 Aug 2019 10:15:54 +0100
Subject: RFR: [8u] 8141570: Fix Zero interpreter build for
 --disable-precompiled-headers
In-Reply-To: <5935ba25ce64cfc747e9717ca1a742d7f35c0ec7.camel@redhat.com>
References: <db4bf4b5-2263-ef35-210a-3049f1e9dfbe@redhat.com>
 <5935ba25ce64cfc747e9717ca1a742d7f35c0ec7.camel@redhat.com>
Message-ID: <CABi63P6rXW8QW4UPHW2rFaXZm+dGKOoyNgGRtVSDqSHc+19uTA@mail.gmail.com>

On Thu, 22 Aug 2019 at 09:52, Severin Gehwolf <sgehwolf at redhat.com> wrote:
>
> Hi Andrew,
>
> On Wed, 2019-08-21 at 20:33 +0100, Andrew John Hughes wrote:
> > This is the first of a series of four changes to support -Wreturn-type
> > in OpenJDK 8u. The -Wreturn-type warning catches instances where control
> > flow exits a non-void function without returning a value. This can
> > combine with compiler optimisations in some cases to cause runtime
> > crashes. The warning is turned on by default in GCC 8 [0], causing the
> > build to fail if it is not explicitly disabled.
> >
> > The subsequent changes are JDK-8062808 to apply the warning and fix
> > issues in the default build, JDK-8143245 to fix issues in the Zero build
> > and JDK-8197981 to fix one remaining Zero issue on 32-bit platforms only.
> >
> > This change ensures the Zero build is not broken by 8062808 by disabling
> > -Wreturn-type in the Zero makefile.
> >
> > Changes in the backport process:
> >
> > * The G1 changes are dropped as 8u does not contain JDK-8073013, which
> > introduces g1EvacStats.*
> > * I've changed the ifeq ($(USE_CLANG), true) to ifeq
> > ($(JVM_VARIANT_ZEROSHARK), true). There seems to have been a mistake in
> > the original patch which equated LLVM with clang. What is actually
> > referred to by "some version of llvm do not like -Wundef" is the LLVM
> > headers that Shark is built against, not the clang compiler which also
> > uses LLVM. This made its way through to the new HotSpot build in OpenJDK
> > 9 & 10, but is gone as of JDK-8198724 in OpenJDK 11 and later.
> >
> > This backport has been in IcedTea since 3.8.0 (2018-05-29) [1] and our
> > RHEL RPMs since 2018-06-16 without issue. Builds of current 8u-dev on
> > x86_64 with Zero release and Zero slowdebug succeeded.
> >
> > [0] https://gcc.gnu.org/gcc-8/changes.html
> > [1] https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3548
>
> I don't see any webrev. Did you forget to link to it?
>
> Thanks,
> Severin
>

Ha, got so caught up in explaining all the other stuff, I forgot the
meat of the matter.

Here it is: https://cr.openjdk.java.net/~andrew/openjdk8/8141570/
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222


From sgehwolf at redhat.com  Thu Aug 22 09:33:29 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 22 Aug 2019 11:33:29 +0200
Subject: RFR: [8u] 8141570: Fix Zero interpreter build for
 --disable-precompiled-headers
In-Reply-To: <CABi63P6rXW8QW4UPHW2rFaXZm+dGKOoyNgGRtVSDqSHc+19uTA@mail.gmail.com>
References: <db4bf4b5-2263-ef35-210a-3049f1e9dfbe@redhat.com>
 <5935ba25ce64cfc747e9717ca1a742d7f35c0ec7.camel@redhat.com>
 <CABi63P6rXW8QW4UPHW2rFaXZm+dGKOoyNgGRtVSDqSHc+19uTA@mail.gmail.com>
Message-ID: <2044ef60ff55d039e0dd1195f17d5383d252926f.camel@redhat.com>

On Thu, 2019-08-22 at 10:15 +0100, Andrew Hughes wrote:
> Here it is: https://cr.openjdk.java.net/~andrew/openjdk8/8141570/

Looks good.

Thanks,
Severin



From erik.joelsson at oracle.com  Thu Aug 22 21:22:55 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 22 Aug 2019 14:22:55 -0700
Subject: RFR: JDK-8230067: Add optional automatic retry when running jtreg
 tests
Message-ID: <0dff2b35-4537-6579-22b2-8286da627e84@oracle.com>

For some notoriously unstable client tests, we need the ability to 
automatically retry them a few times. This can be achieved with a simple 
loop around running jtreg from RunTest.gmk and by using the 
-status:error,fail parameter on the retry runs. This parameter was fixed 
to actually work in this way in jtreg 4.2 b15.

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

Webrev: http://cr.openjdk.java.net/~erikj/8230067/webrev.01/index.html

/Erik



From philip.race at oracle.com  Thu Aug 22 22:02:25 2019
From: philip.race at oracle.com (Phil Race)
Date: Thu, 22 Aug 2019 15:02:25 -0700
Subject: RFR: JDK-8230067: Add optional automatic retry when running jtreg
 tests
In-Reply-To: <0dff2b35-4537-6579-22b2-8286da627e84@oracle.com>
References: <0dff2b35-4537-6579-22b2-8286da627e84@oracle.com>
Message-ID: <d3d437c9-1fcc-510d-4e0d-fe3789821c3c@oracle.com>

+1 from me

Note to others : I already tested Erik's RunTests.gmk updates with the 
pre-promoted jtreg b15

-phil.

On 8/22/19 2:22 PM, Erik Joelsson wrote:
> For some notoriously unstable client tests, we need the ability to 
> automatically retry them a few times. This can be achieved with a 
> simple loop around running jtreg from RunTest.gmk and by using the 
> -status:error,fail parameter on the retry runs. This parameter was 
> fixed to actually work in this way in jtreg 4.2 b15.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8230067
>
> Webrev: http://cr.openjdk.java.net/~erikj/8230067/webrev.01/index.html
>
> /Erik
>



From wangxue at loongson.cn  Fri Aug 23 02:54:18 2019
From: wangxue at loongson.cn (Wang Xue)
Date: Fri, 23 Aug 2019 10:54:18 +0800
Subject: Update test document by changing "TIMEOUT" to "TIMEOUT_FACTOR"
Message-ID: <7ae8f2c2-636b-efe9-f6df-c31656c69265@loongson.cn>

Hi all,

The test document has not been updated completely when changing 
"TIMEOUT" to "TIMEOUT_FACTOR" (JDK-8217634).

It needs to be updated.


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

Webrev: http://cr.openjdk.java.net/~aoqi/8230079/webrev.00/


Could you please review it?


Thanks,

Wang Xue




From claes.redestad at oracle.com  Fri Aug 23 13:08:51 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 23 Aug 2019 15:08:51 +0200
Subject: RFR: 8230043: Lazily load libverify
Message-ID: <ffc803cd-ec4c-b2fc-4d61-ba12d40dcebe@oracle.com>

Hi,

please review this cleanup to untangle the old bytecode verifier
(libverify). It's currently linked and loaded eagerly and early during
bootstrap.

Webrev: http://cr.openjdk.java.net/~redestad/8230043/webrev.00/
Bug:    https://bugs.openjdk.java.net/browse/JDK-8230043

- removes dependency on libverify from libjava by moving the 
check_format.c functions into libjava (they don't need to be exported 
via JNI)
- fixed build to not link libjava with libverify
- removes the eager initialization of libverify in
os::native_java_library
- removes the verify_stubs and directs verifier.cpp to load and call 
VerifyClassForMajorVersion in libverify directly. The initialization
is synchronized on a new mutex, Verify_lock
- remove the unused VerifyClass entry point and simplify code in the
verifier by removing some indirections

Testing: tier1-4

Thanks!

/Claes


From sgehwolf at redhat.com  Fri Aug 23 13:59:43 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 23 Aug 2019 15:59:43 +0200
Subject: [11u] RFR: 8211727: Adjust default concurrency settings for running
 tests on Sparc
Message-ID: <a6ac382f9ee10ba448cd679241e07823332744e0.camel@redhat.com>

Hi,

Please review this dependency patch of a bug I'd like to backport (JDK-
8214003). It does not apply cleanly - due to JDK-8212028 missing in
jdk11u[1], but the changes needed are quite trivial:

1)
JTREG_TIMEOUT_FACTOR => JTREG_TIMEOUT

2)
test/hotspot/jtreg/compiler/jsr292/ContinuousCallSiteTargetChange.java
change omitted since the test in JDK 11u does not have /timeout=300.

Bug: https://bugs.openjdk.java.net/browse/JDK-8211727
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8211727/jdk11/01/webrev/
Original change: http://hg.openjdk.java.net/jdk/jdk/rev/6b05634db714

Tested this on Linux x86_64 tier1 and verified timeout continues to be
set at 4. Tests on sparc would be welcome.

Thoughts?

Thanks,
Severin

[1] 8212028: Use run-test makefile framework for testing in
    Oracle's Mach5. Quite a big change. Does not seem suitable for
    JDK 11u.



From sgehwolf at redhat.com  Fri Aug 23 15:15:04 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 23 Aug 2019 17:15:04 +0200
Subject: [11u] RFR: 8214003: Limit default test jobs based on memory size
Message-ID: <c928f3d4bc5b38a9fa1b0f2bef9327097097a9d6.camel@redhat.com>

Hi,

Please review this backport of a reliability fix for running tests.
Currently on certain machines where num_cores/2 > mem_in_gb/2 there is
a risk of tests failing due to memory issues. JTREG's -concurrency
setting will currently be num_cures/2 and the available memory for this
might not be sufficient to run the tests.

The JDK 12 patch didn't apply cleanly due to some whitespace/context
differences and a difference in argument's numbers in
RunTestsPrebuilt.gmk (due to jcov work not present in JDK 11. i.e. JDK-
8217761 and friends). The patch had to be done manually.

This patch depends on the backport for JDK-8211727 here:
http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-August/001747.html

Bug: https://bugs.openjdk.java.net/browse/JDK-8214003
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214003/jdk11/01/webrev/
original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/8c887dcd5d90

Testing: tier1 on Linux x86_64. Smoke tested "make run-test-prebuilt".
I didn't have access to a specific system which matches the conditions
for this bug to surface, though. Appreciate any testers.

Thoughts?

Thanks,
Severin



From erik.joelsson at oracle.com  Fri Aug 23 15:28:15 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Aug 2019 08:28:15 -0700
Subject: Update test document by changing "TIMEOUT" to "TIMEOUT_FACTOR"
In-Reply-To: <7ae8f2c2-636b-efe9-f6df-c31656c69265@loongson.cn>
References: <7ae8f2c2-636b-efe9-f6df-c31656c69265@loongson.cn>
Message-ID: <2d218bf5-dad0-8642-ee78-578db82babe8@oracle.com>

Looks good!

/Erik

On 2019-08-22 19:54, Wang Xue wrote:
> Hi all,
>
> The test document has not been updated completely when changing 
> "TIMEOUT" to "TIMEOUT_FACTOR" (JDK-8217634).
>
> It needs to be updated.
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8230079
>
> Webrev: http://cr.openjdk.java.net/~aoqi/8230079/webrev.00/
>
>
> Could you please review it?
>
>
> Thanks,
>
> Wang Xue
>
>


From erik.joelsson at oracle.com  Fri Aug 23 15:29:27 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Aug 2019 08:29:27 -0700
Subject: RFR: 8230043: Lazily load libverify
In-Reply-To: <ffc803cd-ec4c-b2fc-4d61-ba12d40dcebe@oracle.com>
References: <ffc803cd-ec4c-b2fc-4d61-ba12d40dcebe@oracle.com>
Message-ID: <c67a8127-ee93-c693-7da3-daebba3d8edd@oracle.com>

Build change looks good.

/Erik

On 2019-08-23 06:08, Claes Redestad wrote:
> Hi,
>
> please review this cleanup to untangle the old bytecode verifier
> (libverify). It's currently linked and loaded eagerly and early during
> bootstrap.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8230043/webrev.00/
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8230043
>
> - removes dependency on libverify from libjava by moving the 
> check_format.c functions into libjava (they don't need to be exported 
> via JNI)
> - fixed build to not link libjava with libverify
> - removes the eager initialization of libverify in
> os::native_java_library
> - removes the verify_stubs and directs verifier.cpp to load and call 
> VerifyClassForMajorVersion in libverify directly. The initialization
> is synchronized on a new mutex, Verify_lock
> - remove the unused VerifyClass entry point and simplify code in the
> verifier by removing some indirections
>
> Testing: tier1-4
>
> Thanks!
>
> /Claes


From erik.joelsson at oracle.com  Fri Aug 23 15:33:02 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Aug 2019 08:33:02 -0700
Subject: [11u] RFR: 8214003: Limit default test jobs based on memory size
In-Reply-To: <c928f3d4bc5b38a9fa1b0f2bef9327097097a9d6.camel@redhat.com>
References: <c928f3d4bc5b38a9fa1b0f2bef9327097097a9d6.camel@redhat.com>
Message-ID: <580ce9e1-52c3-f426-cb98-5185ca50b15a@oracle.com>

Looks good to me.

/Erik

On 2019-08-23 08:15, Severin Gehwolf wrote:
> Hi,
>
> Please review this backport of a reliability fix for running tests.
> Currently on certain machines where num_cores/2 > mem_in_gb/2 there is
> a risk of tests failing due to memory issues. JTREG's -concurrency
> setting will currently be num_cures/2 and the available memory for this
> might not be sufficient to run the tests.
>
> The JDK 12 patch didn't apply cleanly due to some whitespace/context
> differences and a difference in argument's numbers in
> RunTestsPrebuilt.gmk (due to jcov work not present in JDK 11. i.e. JDK-
> 8217761 and friends). The patch had to be done manually.
>
> This patch depends on the backport for JDK-8211727 here:
> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-August/001747.html
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8214003
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214003/jdk11/01/webrev/
> original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/8c887dcd5d90
>
> Testing: tier1 on Linux x86_64. Smoke tested "make run-test-prebuilt".
> I didn't have access to a specific system which matches the conditions
> for this bug to surface, though. Appreciate any testers.
>
> Thoughts?
>
> Thanks,
> Severin
>


From erik.joelsson at oracle.com  Fri Aug 23 15:33:15 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Aug 2019 08:33:15 -0700
Subject: [11u] RFR: 8211727: Adjust default concurrency settings for
 running tests on Sparc
In-Reply-To: <a6ac382f9ee10ba448cd679241e07823332744e0.camel@redhat.com>
References: <a6ac382f9ee10ba448cd679241e07823332744e0.camel@redhat.com>
Message-ID: <47931106-16c1-c936-51a7-8c366ed031e3@oracle.com>

Looks good to me.

/Erik

On 2019-08-23 06:59, Severin Gehwolf wrote:
> Hi,
>
> Please review this dependency patch of a bug I'd like to backport (JDK-
> 8214003). It does not apply cleanly - due to JDK-8212028 missing in
> jdk11u[1], but the changes needed are quite trivial:
>
> 1)
> JTREG_TIMEOUT_FACTOR => JTREG_TIMEOUT
>
> 2)
> test/hotspot/jtreg/compiler/jsr292/ContinuousCallSiteTargetChange.java
> change omitted since the test in JDK 11u does not have /timeout=300.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8211727
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8211727/jdk11/01/webrev/
> Original change: http://hg.openjdk.java.net/jdk/jdk/rev/6b05634db714
>
> Tested this on Linux x86_64 tier1 and verified timeout continues to be
> set at 4. Tests on sparc would be welcome.
>
> Thoughts?
>
> Thanks,
> Severin
>
> [1] 8212028: Use run-test makefile framework for testing in
>      Oracle's Mach5. Quite a big change. Does not seem suitable for
>      JDK 11u.
>


From claes.redestad at oracle.com  Fri Aug 23 15:39:14 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 23 Aug 2019 17:39:14 +0200
Subject: RFR: 8230043: Lazily load libverify
In-Reply-To: <c67a8127-ee93-c693-7da3-daebba3d8edd@oracle.com>
References: <ffc803cd-ec4c-b2fc-4d61-ba12d40dcebe@oracle.com>
 <c67a8127-ee93-c693-7da3-daebba3d8edd@oracle.com>
Message-ID: <15f5b4d3-0e27-f48a-d209-4cdaf6876eeb@oracle.com>

On 2019-08-23 17:29, Erik Joelsson wrote:
> Build change looks good.
> 
> /Erik

Thanks for reviewing!

/Claes


From sgehwolf at redhat.com  Fri Aug 23 15:43:04 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 23 Aug 2019 17:43:04 +0200
Subject: [11u] RFR: 8211727: Adjust default concurrency settings for
 running tests on Sparc
In-Reply-To: <47931106-16c1-c936-51a7-8c366ed031e3@oracle.com>
References: <a6ac382f9ee10ba448cd679241e07823332744e0.camel@redhat.com>
 <47931106-16c1-c936-51a7-8c366ed031e3@oracle.com>
Message-ID: <90866c00ea48a72ecb17cb34fb6a3ef5afb048f8.camel@redhat.com>

On Fri, 2019-08-23 at 08:33 -0700, Erik Joelsson wrote:
> Looks good to me.

Thank you, Erik!

Cheers,
Severin



From sgehwolf at redhat.com  Fri Aug 23 15:43:52 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 23 Aug 2019 17:43:52 +0200
Subject: [11u] RFR: 8214003: Limit default test jobs based on memory size
In-Reply-To: <580ce9e1-52c3-f426-cb98-5185ca50b15a@oracle.com>
References: <c928f3d4bc5b38a9fa1b0f2bef9327097097a9d6.camel@redhat.com>
 <580ce9e1-52c3-f426-cb98-5185ca50b15a@oracle.com>
Message-ID: <cff023523df97a2859bd21fac0d94e7f352a9c79.camel@redhat.com>

On Fri, 2019-08-23 at 08:33 -0700, Erik Joelsson wrote:
> Looks good to me.

Thanks, Erik. Appreciate the review!

Cheers,
Severin



From erik.joelsson at oracle.com  Fri Aug 23 21:10:58 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Aug 2019 14:10:58 -0700
Subject: RFR: JDK-8230067: Add optional automatic retry when running jtreg
 tests
In-Reply-To: <0dff2b35-4537-6579-22b2-8286da627e84@oracle.com>
References: <0dff2b35-4537-6579-22b2-8286da627e84@oracle.com>
Message-ID: <83147bef-b902-cc09-4ae6-78887acdab63@oracle.com>

There seems to be a bug in the new jtreg version, so need to hold off on 
this.

/Erik

On 2019-08-22 14:22, Erik Joelsson wrote:
> For some notoriously unstable client tests, we need the ability to 
> automatically retry them a few times. This can be achieved with a 
> simple loop around running jtreg from RunTest.gmk and by using the 
> -status:error,fail parameter on the retry runs. This parameter was 
> fixed to actually work in this way in jtreg 4.2 b15.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8230067
>
> Webrev: http://cr.openjdk.java.net/~erikj/8230067/webrev.01/index.html
>
> /Erik
>


From wangxue at loongson.cn  Mon Aug 26 01:24:22 2019
From: wangxue at loongson.cn (Wang Xue)
Date: Mon, 26 Aug 2019 09:24:22 +0800
Subject: Update test document by changing "TIMEOUT" to "TIMEOUT_FACTOR"
In-Reply-To: <2d218bf5-dad0-8642-ee78-578db82babe8@oracle.com>
References: <7ae8f2c2-636b-efe9-f6df-c31656c69265@loongson.cn>
 <2d218bf5-dad0-8642-ee78-578db82babe8@oracle.com>
Message-ID: <ed86b8c3-9523-1839-f601-9cdc2f1cdc24@loongson.cn>

Hi Erik,

Thanks for your review.

Could you please sponsor it for me?

Cheers,
Wang Xue

? 8/23/19 23:28, Erik Joelsson ??:
> Looks good!
>
> /Erik
>
> On 2019-08-22 19:54, Wang Xue wrote:
>> Hi all,
>>
>> The test document has not been updated completely when changing 
>> "TIMEOUT" to "TIMEOUT_FACTOR" (JDK-8217634).
>>
>> It needs to be updated.
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230079
>>
>> Webrev: http://cr.openjdk.java.net/~aoqi/8230079/webrev.00/
>>
>>
>> Could you please review it?
>>
>>
>> Thanks,
>>
>> Wang Xue
>>
>>
>


From david.holmes at oracle.com  Mon Aug 26 05:12:15 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 26 Aug 2019 15:12:15 +1000
Subject: RFR: 8230043: Lazily load libverify
In-Reply-To: <ffc803cd-ec4c-b2fc-4d61-ba12d40dcebe@oracle.com>
References: <ffc803cd-ec4c-b2fc-4d61-ba12d40dcebe@oracle.com>
Message-ID: <b17b0375-4f04-1c1f-6ea6-8ba7d649077c@oracle.com>

Hi Claes,

This cleanup all appears fine to me.

The unused Mutex declarations might be better handled in a separate RFE 
but I don't insist. You could file the RFE and still fix together in 
this one changeset.

> Testing: tier1-4

Do you know which tests actually test the older verifier? Just thinking 
that it might be a good idea to make them more obvious.

Thanks,
David

On 23/08/2019 11:08 pm, Claes Redestad wrote:
> Hi,
> 
> please review this cleanup to untangle the old bytecode verifier
> (libverify). It's currently linked and loaded eagerly and early during
> bootstrap.
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8230043/webrev.00/
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8230043
> 
> - removes dependency on libverify from libjava by moving the 
> check_format.c functions into libjava (they don't need to be exported 
> via JNI)
> - fixed build to not link libjava with libverify
> - removes the eager initialization of libverify in
> os::native_java_library
> - removes the verify_stubs and directs verifier.cpp to load and call 
> VerifyClassForMajorVersion in libverify directly. The initialization
> is synchronized on a new mutex, Verify_lock
> - remove the unused VerifyClass entry point and simplify code in the
> verifier by removing some indirections
> 
> Testing: tier1-4
> 
> Thanks!
> 
> /Claes


From claes.redestad at oracle.com  Mon Aug 26 10:46:18 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 26 Aug 2019 12:46:18 +0200
Subject: RFR: 8230043: Lazily load libverify
In-Reply-To: <b17b0375-4f04-1c1f-6ea6-8ba7d649077c@oracle.com>
References: <ffc803cd-ec4c-b2fc-4d61-ba12d40dcebe@oracle.com>
 <b17b0375-4f04-1c1f-6ea6-8ba7d649077c@oracle.com>
Message-ID: <d0356274-0503-836a-f067-a2b7326a2be2@oracle.com>

Hi David,

On 2019-08-26 07:12, David Holmes wrote:
> Hi Claes,
> 
> This cleanup all appears fine to me.
> 
> The unused Mutex declarations might be better handled in a separate RFE 
> but I don't insist. You could file the RFE and still fix together in 
> this one changeset.

fair enough: https://bugs.openjdk.java.net/browse/JDK-8230140

> 
>> Testing: tier1-4
> 
> Do you know which tests actually test the older verifier? Just thinking 
> that it might be a good idea to make them more obvious.

I'm not too familiar with the testing in this area, but was told there
are quite a few JCK tests that test the byte code verifiers, libverify
included, and that we run the full set of those in tier3.

Thanks

/Claes


From erik.joelsson at oracle.com  Mon Aug 26 14:17:12 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 26 Aug 2019 07:17:12 -0700
Subject: Update test document by changing "TIMEOUT" to "TIMEOUT_FACTOR"
In-Reply-To: <ed86b8c3-9523-1839-f601-9cdc2f1cdc24@loongson.cn>
References: <7ae8f2c2-636b-efe9-f6df-c31656c69265@loongson.cn>
 <2d218bf5-dad0-8642-ee78-578db82babe8@oracle.com>
 <ed86b8c3-9523-1839-f601-9cdc2f1cdc24@loongson.cn>
Message-ID: <54ea8088-ce64-3864-7720-7c3bc46ead32@oracle.com>

Done.

/Erik

On 2019-08-25 18:24, Wang Xue wrote:
>
> Hi Erik,
>
> Thanks for your review.
>
> Could you please sponsor it for me?
>
> Cheers,
> Wang Xue
> ? 8/23/19 23:28, Erik Joelsson ??:
>> Looks good!
>>
>> /Erik
>>
>> On 2019-08-22 19:54, Wang Xue wrote:
>>> Hi all,
>>>
>>> The test document has not been updated completely when changing 
>>> "TIMEOUT" to "TIMEOUT_FACTOR" (JDK-8217634).
>>>
>>> It needs to be updated.
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230079
>>>
>>> Webrev: http://cr.openjdk.java.net/~aoqi/8230079/webrev.00/
>>>
>>>
>>> Could you please review it?
>>>
>>>
>>> Thanks,
>>>
>>> Wang Xue
>>>
>>>
>>


From wangxue at loongson.cn  Tue Aug 27 01:42:47 2019
From: wangxue at loongson.cn (Wang Xue)
Date: Tue, 27 Aug 2019 09:42:47 +0800
Subject: Update test document by changing "TIMEOUT" to "TIMEOUT_FACTOR"
In-Reply-To: <54ea8088-ce64-3864-7720-7c3bc46ead32@oracle.com>
References: <7ae8f2c2-636b-efe9-f6df-c31656c69265@loongson.cn>
 <2d218bf5-dad0-8642-ee78-578db82babe8@oracle.com>
 <ed86b8c3-9523-1839-f601-9cdc2f1cdc24@loongson.cn>
 <54ea8088-ce64-3864-7720-7c3bc46ead32@oracle.com>
Message-ID: <e393ca75-94c0-75e8-a7bd-0529f37bae32@loongson.cn>

Hi Erik,


Thanks a lot.


Wang Xue


? 8/26/19 22:17, Erik Joelsson ??:
>
> Done.
>
> /Erik
>
> On 2019-08-25 18:24, Wang Xue wrote:
>>
>> Hi Erik,
>>
>> Thanks for your review.
>>
>> Could you please sponsor it for me?
>>
>> Cheers,
>> Wang Xue
>> ? 8/23/19 23:28, Erik Joelsson ??:
>>> Looks good!
>>>
>>> /Erik
>>>
>>> On 2019-08-22 19:54, Wang Xue wrote:
>>>> Hi all,
>>>>
>>>> The test document has not been updated completely when changing 
>>>> "TIMEOUT" to "TIMEOUT_FACTOR" (JDK-8217634).
>>>>
>>>> It needs to be updated.
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230079
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~aoqi/8230079/webrev.00/
>>>>
>>>>
>>>> Could you please review it?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Wang Xue
>>>>
>>>>
>>>


From david.holmes at oracle.com  Thu Aug 29 23:12:26 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Aug 2019 09:12:26 +1000
Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler
In-Reply-To: <AM6PR02MB5078275D0A66E9C7FA9F824093A20@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078B03A7B3B1CAE9C1031F093A20@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <HE1PR0201MB2475A780C8DE0B0363A124EF9AA20@HE1PR0201MB2475.eurprd02.prod.outlook.com>
 <AM6PR02MB5078275D0A66E9C7FA9F824093A20@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <5235c148-f3af-7aad-a50d-769de5cd5e28@oracle.com>

Hi Matthias,

cc'ing build-dev for build changes.

But they look fine to me as do the main changes.

A couple of nits:

- ensure all copyright headers are updated for 2019

- in globalDefinitions_xlc.hpp this comment seems no longer necessary

   // __IBMCPP__ is not defined any more with xlclang++

But that said, if __IBMCPP__ is no longer defined then it seems a fix is 
needed in ./share/runtime/vm_version.cpp as well.

Cheers,
David

On 30/08/2019 1:41 am, Baesken, Matthias wrote:
> Hi Martin, I agree  about the m4 files .
> New webrev , this additionally touches    toolchain.m4  and flags-cflags.m4
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.1/
> 
> Thanks, Matthias
> 
>> -----Original Message-----
>> From: Doerr, Martin <martin.doerr at sap.com>
>> Sent: Donnerstag, 29. August 2019 16:19
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; 'ppc-aix-port-
>> dev at openjdk.java.net' <ppc-aix-port-dev at openjdk.java.net>
>> Subject: RE: RFR: 8224214: [AIX] Remove support for legacy xlc compiler
>>
>> Hi Matthias,
>>
>> nice cleanup. Looks good to me.
>>
>> We can also require availability of xlclang++ in toolchain.m4. I think some of
>> the changes only work with this compiler.
>>
>> Thanks,
>> Martin
>>
>>
>>> -----Original Message-----
>>> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf
>> Of
>>> Baesken, Matthias
>>> Sent: Donnerstag, 29. August 2019 15:41
>>> To: 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>;
>>> 'ppc-aix-port-dev at openjdk.java.net' <ppc-aix-port-
>> dev at openjdk.java.net>
>>> Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler
>>>
>>> Hello, please review the following change .
>>> For OpenJDK 13 we've moved to XLC 16 as required compiler.
>>> However  we have still   a lot of workarounds and checks in the codebase
>> for
>>> the older xlc  compilers.
>>> This changes removes such changes .
>>>
>>> Additionally  it  adjusts   the compiler version check in
>>> hotspot/share/utilities/globalDefinitions_xlc.hpp
>>> and 2 typos in os_aix  are fixed .
>>>
>>>
>>> When  8224214   was created a while ago ,  it was discussed on the mailing
>> list
>>> :
>>>
>>> "we still set some '-qlanglvl' options for C++ which aren't supported by the
>>> new compiler [xlc16/xlclang++] either" .
>>> Those options  generated lots of warnings ,   so they  were removed
>> already
>>> so  no need to remove them  in  this change .
>>>
>>> (  In jdk11  which is built  with xlc12   they can still be found :
>>> flags-cflags.m4:540: -qalias=noansi -qstrict -qtls=default -qlanglvl=c99vla \
>>> flags-cflags.m4:541: -qlanglvl=noredefmac -qnortti -qnoeh -qignerrno"
>>> )
>>>
>>>
>>> Bug/webrev :
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8224214
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.0/
>>>
>>>
>>> Thanks, Matthias


From matthias.baesken at sap.com  Fri Aug 30 07:55:19 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 30 Aug 2019 07:55:19 +0000
Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler
In-Reply-To: <5235c148-f3af-7aad-a50d-769de5cd5e28@oracle.com>
References: <AM6PR02MB5078B03A7B3B1CAE9C1031F093A20@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <HE1PR0201MB2475A780C8DE0B0363A124EF9AA20@HE1PR0201MB2475.eurprd02.prod.outlook.com>
 <AM6PR02MB5078275D0A66E9C7FA9F824093A20@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <5235c148-f3af-7aad-a50d-769de5cd5e28@oracle.com>
Message-ID: <AM6PR02MB5078F8284499D66BBD753E8C93BD0@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hi David , thanks  for forwarding to build-dev + your comments . May I add you as reviewer?

New webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.2/

-adjusted  the copyright year in make/autoconf/toolchain.m4
-removed the comment  as suggested by you

> But that said, if __IBMCPP__ is no longer defined then it seems a fix is
> needed in ./share/runtime/vm_version.cpp as well.

-removed  __IBMCPP__  from  share/runtime/vm_version.cpp    (more a cleanup than something that is really needed) ;
reason is that  xlc16/xlclang++   comes with a very rich set   of  compiler - macros,   especially  the "usual"  clang and GNUC macros are all set ; see :

$fgrep GNUC xclangplus.txt
#define __GNUC_MINOR__ 2
#define __GNUC_PATCHLEVEL__ 1
#define __GNUC_STDC_INLINE__ 1
#define __GNUC__ 4

$ fgrep clang xclangplus.txt
#define __clang__ 1
#define __clang_major__ 4
#define __clang_minor__ 0
#define __clang_patchlevel__ 1
#define __clang_version__ "4.0.1 (tags/RELEASE_401/final)"


$ fgrep __VERSION__ xclangplus.txt
#define __VERSION__ "IBM XL C/C++ for AIX, Version 16.1.0.1"

So we  would run into the clang -case  in  vm_version.cpp    and there use  the __VERSION__ info  that is pretty  good IMHO .

Best regards, Matthias


> 
> Hi Matthias,
> 
> cc'ing build-dev for build changes.
> 
> But they look fine to me as do the main changes.
> 
> A couple of nits:
> 
> - ensure all copyright headers are updated for 2019
> 
> - in globalDefinitions_xlc.hpp this comment seems no longer necessary
> 
>    // __IBMCPP__ is not defined any more with xlclang++
> 
> But that said, if __IBMCPP__ is no longer defined then it seems a fix is
> needed in ./share/runtime/vm_version.cpp as well.
> 
> Cheers,
> David
> 
> On 30/08/2019 1:41 am, Baesken, Matthias wrote:
> > Hi Martin, I agree  about the m4 files .
> > New webrev , this additionally touches    toolchain.m4  and flags-cflags.m4
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.1/
> >
> > Thanks, Matthias
> >
> >> -----Original Message-----
> >> From: Doerr, Martin <martin.doerr at sap.com>
> >> Sent: Donnerstag, 29. August 2019 16:19
> >> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
> >> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; 'ppc-aix-port-
> >> dev at openjdk.java.net' <ppc-aix-port-dev at openjdk.java.net>
> >> Subject: RE: RFR: 8224214: [AIX] Remove support for legacy xlc compiler
> >>
> >> Hi Matthias,
> >>
> >> nice cleanup. Looks good to me.
> >>
> >> We can also require availability of xlclang++ in toolchain.m4. I think some
> of
> >> the changes only work with this compiler.
> >>
> >> Thanks,
> >> Martin
> >>
> >>
> >>> -----Original Message-----
> >>> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On
> Behalf
> >> Of
> >>> Baesken, Matthias
> >>> Sent: Donnerstag, 29. August 2019 15:41
> >>> To: 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>;
> >>> 'ppc-aix-port-dev at openjdk.java.net' <ppc-aix-port-
> >> dev at openjdk.java.net>
> >>> Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler
> >>>
> >>> Hello, please review the following change .
> >>> For OpenJDK 13 we've moved to XLC 16 as required compiler.
> >>> However  we have still   a lot of workarounds and checks in the codebase
> >> for
> >>> the older xlc  compilers.
> >>> This changes removes such changes .
> >>>
> >>> Additionally  it  adjusts   the compiler version check in
> >>> hotspot/share/utilities/globalDefinitions_xlc.hpp
> >>> and 2 typos in os_aix  are fixed .
> >>>
> >>>
> >>> When  8224214   was created a while ago ,  it was discussed on the
> mailing
> >> list
> >>> :
> >>>
> >>> "we still set some '-qlanglvl' options for C++ which aren't supported by
> the
> >>> new compiler [xlc16/xlclang++] either" .
> >>> Those options  generated lots of warnings ,   so they  were removed
> >> already
> >>> so  no need to remove them  in  this change .
> >>>
> >>> (  In jdk11  which is built  with xlc12   they can still be found :
> >>> flags-cflags.m4:540: -qalias=noansi -qstrict -qtls=default -qlanglvl=c99vla
> \
> >>> flags-cflags.m4:541: -qlanglvl=noredefmac -qnortti -qnoeh -qignerrno"
> >>> )
> >>>
> >>>
> >>> Bug/webrev :
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8224214
> >>>
> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.0/
> >>>
> >>>
> >>> Thanks, Matthias

From david.holmes at oracle.com  Fri Aug 30 13:33:44 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Aug 2019 23:33:44 +1000
Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler
In-Reply-To: <AM6PR02MB5078F8284499D66BBD753E8C93BD0@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078B03A7B3B1CAE9C1031F093A20@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <HE1PR0201MB2475A780C8DE0B0363A124EF9AA20@HE1PR0201MB2475.eurprd02.prod.outlook.com>
 <AM6PR02MB5078275D0A66E9C7FA9F824093A20@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <5235c148-f3af-7aad-a50d-769de5cd5e28@oracle.com>
 <AM6PR02MB5078F8284499D66BBD753E8C93BD0@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <e2459889-ca13-c9e5-2ca0-c0f7e08ebe2b@oracle.com>

Hi Matthias,

On 30/08/2019 5:55 pm, Baesken, Matthias wrote:
> Hi David , thanks  for forwarding to build-dev + your comments . May I add you as reviewer?

Of course.

> 
> New webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.2/

Updates look good.

Thanks,
David
-----

> -adjusted  the copyright year in make/autoconf/toolchain.m4
> -removed the comment  as suggested by you
> 
>> But that said, if __IBMCPP__ is no longer defined then it seems a fix is
>> needed in ./share/runtime/vm_version.cpp as well.
> 
> -removed  __IBMCPP__  from  share/runtime/vm_version.cpp    (more a cleanup than something that is really needed) ;
> reason is that  xlc16/xlclang++   comes with a very rich set   of  compiler - macros,   especially  the "usual"  clang and GNUC macros are all set ; see :
> 
> $fgrep GNUC xclangplus.txt
> #define __GNUC_MINOR__ 2
> #define __GNUC_PATCHLEVEL__ 1
> #define __GNUC_STDC_INLINE__ 1
> #define __GNUC__ 4
> 
> $ fgrep clang xclangplus.txt
> #define __clang__ 1
> #define __clang_major__ 4
> #define __clang_minor__ 0
> #define __clang_patchlevel__ 1
> #define __clang_version__ "4.0.1 (tags/RELEASE_401/final)"
> 
> 
> $ fgrep __VERSION__ xclangplus.txt
> #define __VERSION__ "IBM XL C/C++ for AIX, Version 16.1.0.1"
> 
> So we  would run into the clang -case  in  vm_version.cpp    and there use  the __VERSION__ info  that is pretty  good IMHO .
> 
> Best regards, Matthias
> 
> 
>>
>> Hi Matthias,
>>
>> cc'ing build-dev for build changes.
>>
>> But they look fine to me as do the main changes.
>>
>> A couple of nits:
>>
>> - ensure all copyright headers are updated for 2019
>>
>> - in globalDefinitions_xlc.hpp this comment seems no longer necessary
>>
>>     // __IBMCPP__ is not defined any more with xlclang++
>>
>> But that said, if __IBMCPP__ is no longer defined then it seems a fix is
>> needed in ./share/runtime/vm_version.cpp as well.
>>
>> Cheers,
>> David
>>
>> On 30/08/2019 1:41 am, Baesken, Matthias wrote:
>>> Hi Martin, I agree  about the m4 files .
>>> New webrev , this additionally touches    toolchain.m4  and flags-cflags.m4
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.1/
>>>
>>> Thanks, Matthias
>>>
>>>> -----Original Message-----
>>>> From: Doerr, Martin <martin.doerr at sap.com>
>>>> Sent: Donnerstag, 29. August 2019 16:19
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>>>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; 'ppc-aix-port-
>>>> dev at openjdk.java.net' <ppc-aix-port-dev at openjdk.java.net>
>>>> Subject: RE: RFR: 8224214: [AIX] Remove support for legacy xlc compiler
>>>>
>>>> Hi Matthias,
>>>>
>>>> nice cleanup. Looks good to me.
>>>>
>>>> We can also require availability of xlclang++ in toolchain.m4. I think some
>> of
>>>> the changes only work with this compiler.
>>>>
>>>> Thanks,
>>>> Martin
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On
>> Behalf
>>>> Of
>>>>> Baesken, Matthias
>>>>> Sent: Donnerstag, 29. August 2019 15:41
>>>>> To: 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>;
>>>>> 'ppc-aix-port-dev at openjdk.java.net' <ppc-aix-port-
>>>> dev at openjdk.java.net>
>>>>> Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler
>>>>>
>>>>> Hello, please review the following change .
>>>>> For OpenJDK 13 we've moved to XLC 16 as required compiler.
>>>>> However  we have still   a lot of workarounds and checks in the codebase
>>>> for
>>>>> the older xlc  compilers.
>>>>> This changes removes such changes .
>>>>>
>>>>> Additionally  it  adjusts   the compiler version check in
>>>>> hotspot/share/utilities/globalDefinitions_xlc.hpp
>>>>> and 2 typos in os_aix  are fixed .
>>>>>
>>>>>
>>>>> When  8224214   was created a while ago ,  it was discussed on the
>> mailing
>>>> list
>>>>> :
>>>>>
>>>>> "we still set some '-qlanglvl' options for C++ which aren't supported by
>> the
>>>>> new compiler [xlc16/xlclang++] either" .
>>>>> Those options  generated lots of warnings ,   so they  were removed
>>>> already
>>>>> so  no need to remove them  in  this change .
>>>>>
>>>>> (  In jdk11  which is built  with xlc12   they can still be found :
>>>>> flags-cflags.m4:540: -qalias=noansi -qstrict -qtls=default -qlanglvl=c99vla
>> \
>>>>> flags-cflags.m4:541: -qlanglvl=noredefmac -qnortti -qnoeh -qignerrno"
>>>>> )
>>>>>
>>>>>
>>>>> Bug/webrev :
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8224214
>>>>>
>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.0/
>>>>>
>>>>>
>>>>> Thanks, Matthias


From kim.barrett at oracle.com  Fri Aug 30 17:13:56 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 30 Aug 2019 13:13:56 -0400
Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler
In-Reply-To: <AM6PR02MB5078F8284499D66BBD753E8C93BD0@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078B03A7B3B1CAE9C1031F093A20@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <HE1PR0201MB2475A780C8DE0B0363A124EF9AA20@HE1PR0201MB2475.eurprd02.prod.outlook.com>
 <AM6PR02MB5078275D0A66E9C7FA9F824093A20@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <5235c148-f3af-7aad-a50d-769de5cd5e28@oracle.com>
 <AM6PR02MB5078F8284499D66BBD753E8C93BD0@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <D0903416-22A7-4158-A524-BF0DB19D6C7E@oracle.com>

> On Aug 30, 2019, at 3:55 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hi David , thanks  for forwarding to build-dev + your comments . May I add you as reviewer?
> 
> New webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.2/

Still looks good to me.



From erik.joelsson at oracle.com  Fri Aug 30 15:08:49 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 30 Aug 2019 08:08:49 -0700
Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler
In-Reply-To: <e2459889-ca13-c9e5-2ca0-c0f7e08ebe2b@oracle.com>
References: <AM6PR02MB5078B03A7B3B1CAE9C1031F093A20@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <HE1PR0201MB2475A780C8DE0B0363A124EF9AA20@HE1PR0201MB2475.eurprd02.prod.outlook.com>
 <AM6PR02MB5078275D0A66E9C7FA9F824093A20@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <5235c148-f3af-7aad-a50d-769de5cd5e28@oracle.com>
 <AM6PR02MB5078F8284499D66BBD753E8C93BD0@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <e2459889-ca13-c9e5-2ca0-c0f7e08ebe2b@oracle.com>
Message-ID: <e57b63b5-2416-0f78-a502-69fb5735736c@oracle.com>

Build changes look good.

/Erik

On 2019-08-30 06:33, David Holmes wrote:
> Hi Matthias,
>
> On 30/08/2019 5:55 pm, Baesken, Matthias wrote:
>> Hi David , thanks? for forwarding to build-dev + your comments . May 
>> I add you as reviewer?
>
> Of course.
>
>>
>> New webrev :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.2/
>
> Updates look good.
>
> Thanks,
> David
> -----
>
>> -adjusted? the copyright year in make/autoconf/toolchain.m4
>> -removed the comment? as suggested by you
>>
>>> But that said, if __IBMCPP__ is no longer defined then it seems a 
>>> fix is
>>> needed in ./share/runtime/vm_version.cpp as well.
>>
>> -removed? __IBMCPP__? from? share/runtime/vm_version.cpp (more a 
>> cleanup than something that is really needed) ;
>> reason is that? xlc16/xlclang++?? comes with a very rich set of? 
>> compiler - macros,?? especially? the "usual"? clang and GNUC macros 
>> are all set ; see :
>>
>> $fgrep GNUC xclangplus.txt
>> #define __GNUC_MINOR__ 2
>> #define __GNUC_PATCHLEVEL__ 1
>> #define __GNUC_STDC_INLINE__ 1
>> #define __GNUC__ 4
>>
>> $ fgrep clang xclangplus.txt
>> #define __clang__ 1
>> #define __clang_major__ 4
>> #define __clang_minor__ 0
>> #define __clang_patchlevel__ 1
>> #define __clang_version__ "4.0.1 (tags/RELEASE_401/final)"
>>
>>
>> $ fgrep __VERSION__ xclangplus.txt
>> #define __VERSION__ "IBM XL C/C++ for AIX, Version 16.1.0.1"
>>
>> So we? would run into the clang -case? in? vm_version.cpp??? and 
>> there use? the __VERSION__ info? that is pretty? good IMHO .
>>
>> Best regards, Matthias
>>
>>
>>>
>>> Hi Matthias,
>>>
>>> cc'ing build-dev for build changes.
>>>
>>> But they look fine to me as do the main changes.
>>>
>>> A couple of nits:
>>>
>>> - ensure all copyright headers are updated for 2019
>>>
>>> - in globalDefinitions_xlc.hpp this comment seems no longer necessary
>>>
>>> ??? // __IBMCPP__ is not defined any more with xlclang++
>>>
>>> But that said, if __IBMCPP__ is no longer defined then it seems a 
>>> fix is
>>> needed in ./share/runtime/vm_version.cpp as well.
>>>
>>> Cheers,
>>> David
>>>
>>> On 30/08/2019 1:41 am, Baesken, Matthias wrote:
>>>> Hi Martin, I agree? about the m4 files .
>>>> New webrev , this additionally touches??? toolchain.m4? and 
>>>> flags-cflags.m4
>>>>
>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.1/
>>>>
>>>> Thanks, Matthias
>>>>
>>>>> -----Original Message-----
>>>>> From: Doerr, Martin <martin.doerr at sap.com>
>>>>> Sent: Donnerstag, 29. August 2019 16:19
>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>>>>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; 'ppc-aix-port-
>>>>> dev at openjdk.java.net' <ppc-aix-port-dev at openjdk.java.net>
>>>>> Subject: RE: RFR: 8224214: [AIX] Remove support for legacy xlc 
>>>>> compiler
>>>>>
>>>>> Hi Matthias,
>>>>>
>>>>> nice cleanup. Looks good to me.
>>>>>
>>>>> We can also require availability of xlclang++ in toolchain.m4. I 
>>>>> think some
>>> of
>>>>> the changes only work with this compiler.
>>>>>
>>>>> Thanks,
>>>>> Martin
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On
>>> Behalf
>>>>> Of
>>>>>> Baesken, Matthias
>>>>>> Sent: Donnerstag, 29. August 2019 15:41
>>>>>> To: 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>;
>>>>>> 'ppc-aix-port-dev at openjdk.java.net' <ppc-aix-port-
>>>>> dev at openjdk.java.net>
>>>>>> Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler
>>>>>>
>>>>>> Hello, please review the following change .
>>>>>> For OpenJDK 13 we've moved to XLC 16 as required compiler.
>>>>>> However? we have still?? a lot of workarounds and checks in the 
>>>>>> codebase
>>>>> for
>>>>>> the older xlc? compilers.
>>>>>> This changes removes such changes .
>>>>>>
>>>>>> Additionally? it? adjusts?? the compiler version check in
>>>>>> hotspot/share/utilities/globalDefinitions_xlc.hpp
>>>>>> and 2 typos in os_aix? are fixed .
>>>>>>
>>>>>>
>>>>>> When? 8224214?? was created a while ago ,? it was discussed on the
>>> mailing
>>>>> list
>>>>>> :
>>>>>>
>>>>>> "we still set some '-qlanglvl' options for C++ which aren't 
>>>>>> supported by
>>> the
>>>>>> new compiler [xlc16/xlclang++] either" .
>>>>>> Those options? generated lots of warnings ,?? so they were removed
>>>>> already
>>>>>> so? no need to remove them? in this change .
>>>>>>
>>>>>> (? In jdk11? which is built? with xlc12?? they can still be found :
>>>>>> flags-cflags.m4:540: -qalias=noansi -qstrict -qtls=default 
>>>>>> -qlanglvl=c99vla
>>> \
>>>>>> flags-cflags.m4:541: -qlanglvl=noredefmac -qnortti -qnoeh 
>>>>>> -qignerrno"
>>>>>> )
>>>>>>
>>>>>>
>>>>>> Bug/webrev :
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8224214
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.0/
>>>>>>
>>>>>>
>>>>>> Thanks, Matthias


From joe.darcy at oracle.com  Fri Aug 30 20:12:24 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 30 Aug 2019 13:12:24 -0700
Subject: JDK 14 RFR of JDK-8230373: Use java.io.Serial in generated exception
 types
Message-ID: <4989be37-b9b8-01e5-2e3d-12278166425b@oracle.com>

Hello,

As noted during the code review of JDK-8229997 
(http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062049.html), 
for completeness @java.io.Serial annotation should be included on 
generated exception types.

Please review the patch below which adds these annotations by updating 
the generation script.

Thanks,

-Joe

diff -r 374f3f9dda6f make/scripts/genExceptions.sh
--- a/make/scripts/genExceptions.sh??? Fri Aug 30 14:58:40 2019 -0400
+++ b/make/scripts/genExceptions.sh??? Fri Aug 30 13:10:30 2019 -0700
@@ -1,6 +1,6 @@
 ?#! /bin/sh
 ?#
-# Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights 
reserved.
+# Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
reserved.
 ?# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 ?#
 ?# This code is free software; you can redistribute it and/or modify it
@@ -60,6 +60,7 @@
 ???? extends ${SUPER}
 ?{

+??? @java.io.Serial
 ???? private static final long serialVersionUID = $SVUID;
 ?__END__




From erik.joelsson at oracle.com  Fri Aug 30 20:47:45 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 30 Aug 2019 13:47:45 -0700
Subject: JDK 14 RFR of JDK-8230373: Use java.io.Serial in generated
 exception types
In-Reply-To: <4989be37-b9b8-01e5-2e3d-12278166425b@oracle.com>
References: <4989be37-b9b8-01e5-2e3d-12278166425b@oracle.com>
Message-ID: <9b24495f-8c89-c8ca-3621-758c92fdc48b@oracle.com>

Looks good.

/Erik

On 2019-08-30 13:12, Joe Darcy wrote:
> Hello,
>
> As noted during the code review of JDK-8229997 
> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062049.html), 
> for completeness @java.io.Serial annotation should be included on 
> generated exception types.
>
> Please review the patch below which adds these annotations by updating 
> the generation script.
>
> Thanks,
>
> -Joe
>
> diff -r 374f3f9dda6f make/scripts/genExceptions.sh
> --- a/make/scripts/genExceptions.sh??? Fri Aug 30 14:58:40 2019 -0400
> +++ b/make/scripts/genExceptions.sh??? Fri Aug 30 13:10:30 2019 -0700
> @@ -1,6 +1,6 @@
> ?#! /bin/sh
> ?#
> -# Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights 
> reserved.
> +# Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
> reserved.
> ?# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> ?#
> ?# This code is free software; you can redistribute it and/or modify it
> @@ -60,6 +60,7 @@
> ???? extends ${SUPER}
> ?{
>
> +??? @java.io.Serial
> ???? private static final long serialVersionUID = $SVUID;
> ?__END__
>
>


From Alan.Bateman at oracle.com  Sat Aug 31 06:43:10 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 31 Aug 2019 07:43:10 +0100
Subject: JDK 14 RFR of JDK-8230373: Use java.io.Serial in generated
 exception types
In-Reply-To: <4989be37-b9b8-01e5-2e3d-12278166425b@oracle.com>
References: <4989be37-b9b8-01e5-2e3d-12278166425b@oracle.com>
Message-ID: <886e414e-b291-a4de-b476-e9a3f2f179ed@oracle.com>



On 30/08/2019 21:12, Joe Darcy wrote:
> Hello,
>
> As noted during the code review of JDK-8229997 
> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062049.html), 
> for completeness @java.io.Serial annotation should be included on 
> generated exception types.
>
> Please review the patch below which adds these annotations by updating 
> the generation script.
Looks fine.