Re: [13] RFR: JDK-8225392: Comparison builds are failing due to cacerts file

[Sean Mullan]

On 6/14/19 11:33 AM, Weijun Wang wrote:

Here is the updated webrev

   http://cr.openjdk.java.net/~weijun/8225392/webrev.01/

The only change is ordering in 'keytool -list' and its test.


Looks fine.

--Sean



Thanks,
Max


On Jun 14, 2019, at 7:55 PM, Sean Mullan  wrote:

On 6/14/19 1:49 AM, Weijun Wang wrote:

BTW, something not related but similar: Do you like me to also sort aliases 
alphabetically in the output of "keytool -list"?


Yes, I think that is useful.

--Sean

Re: jdk 14 version string scheme changed?

[Erik Joelsson]

The configure script has parsing logic for interpreting a full version 
string and splitting it into all the parts if you need inspiration.


/Erik

On 2019-06-14 13:51, Martin Buchholz wrote:

Thanks!

(OPT is harder to parse out than I expected ...)

On Fri, Jun 14, 2019 at 12:57 PM Erik Joelsson 
mailto:erik.joels...@oracle.com>> wrote:


Hello Martin,

It is intentional. The extra number is our internal CI build
number. From JDK 14 we have decided to stop rebuilding for
promotion and instead use a build already built and tested in our CI.

The new number is part of the $OPT string as defined in JEP-223 [1].

"$OPT, matching|([-a-zA-Z0-9\.]+)|--- Additional build
information, if desired.In the case of an|internal|build this will
often contain the date and time of the build."

Note that the addition of this particular number is only done on
builds published by Oracle. Other publishers of OpenJDK binaries
are free to add their additional information in that string, and
AFAIK it's common practice to do so.

/Erik

[1] https://openjdk.java.net/jeps/223

On 2019-06-14 12:25, Martin Buchholz wrote:

The first jdk14 build reports:
openjdk full version "14-ea+1-1"
while jdk13 has:
openjdk full version "13-ea+25"

The trailing "-1" looks like a bug - is it intentional?

Re: jdk 14 version string scheme changed?

[Martin Buchholz]

Thanks!

(OPT is harder to parse out than I expected ...)

On Fri, Jun 14, 2019 at 12:57 PM Erik Joelsson 
wrote:

> Hello Martin,
>
> It is intentional. The extra number is our internal CI build number. From
> JDK 14 we have decided to stop rebuilding for promotion and instead use a
> build already built and tested in our CI.
>
> The new number is part of the $OPT string as defined in JEP-223 [1].
>
> "$OPT, matching ([-a-zA-Z0-9\.]+) --- Additional build information, if
> desired. In the case of an internal build this will often contain the
> date and time of the build."
>
> Note that the addition of this particular number is only done on builds
> published by Oracle. Other publishers of OpenJDK binaries are free to add
> their additional information in that string, and AFAIK it's common practice
> to do so.
>
> /Erik
>
> [1] https://openjdk.java.net/jeps/223
> On 2019-06-14 12:25, Martin Buchholz wrote:
>
> The first jdk14 build reports:
> openjdk full version "14-ea+1-1"
> while jdk13 has:
> openjdk full version "13-ea+25"
>
> The trailing "-1" looks like a bug - is it intentional?
>
>

Re: jdk 14 version string scheme changed?

[Erik Joelsson]

Hello Martin,

It is intentional. The extra number is our internal CI build number. 
From JDK 14 we have decided to stop rebuilding for promotion and 
instead use a build already built and tested in our CI.


The new number is part of the $OPT string as defined in JEP-223 [1].

"$OPT, matching|([-a-zA-Z0-9\.]+)|--- Additional build information, if 
desired.In the case of an|internal|build this will often contain the 
date and time of the build."


Note that the addition of this particular number is only done on builds 
published by Oracle. Other publishers of OpenJDK binaries are free to 
add their additional information in that string, and AFAIK it's common 
practice to do so.


/Erik

[1] https://openjdk.java.net/jeps/223

On 2019-06-14 12:25, Martin Buchholz wrote:

The first jdk14 build reports:
openjdk full version "14-ea+1-1"
while jdk13 has:
openjdk full version "13-ea+25"

The trailing "-1" looks like a bug - is it intentional?

jdk 14 version string scheme changed?

[Martin Buchholz]

The first jdk14 build reports:
openjdk full version "14-ea+1-1"
while jdk13 has:
openjdk full version "13-ea+25"

The trailing "-1" looks like a bug - is it intentional?

Re: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3

[Andrew Haley]

Hi,

On 6/12/19 10:35 AM, Nick Gasson wrote:

> Sorry for the delay, I've put an updated webrev here:
> 
> http://cr.openjdk.java.net/~ngasson/8224851/webrev.1/
> 
> Changes since the last patch:
> 
> * Replaced ~((1<<12) - 1) with -1u<<12
> 
> * Use __atomic_add_fetch in Atomic::PlatformAdd #ifdef __clang__
> 
> * Use __builtin_frame_address(0) in os::current_frame()
> 
> * Use placement new / copy assignment in pf()
> 
> I also replaced the call to _get_previous_fp() in os::current_frame() with
> 
>*(intptr_t **)__builtin_frame_address(0);
> 
> As it generates the same code and avoids the `register intptr_t **fp 
> __asm__ (SPELL_REG_FP);' declaration which clang doesn't support. Also 
> the following comment in _get_previous_fp seems to be wrong:
> 
>// fp is for this frame (_get_previous_fp). We want the fp for the
>// caller of os::current_frame*(), so go up two frames. However, for
>// optimized builds, _get_previous_fp() will be inlined, so only go
>// up 1 frame in that case.
>#ifdef _NMT_NOINLINE_
>  return **(intptr_t***)fp;
>#else
>  return *fp;
>#endif
> 
> Even on -O0 gcc won't generate a stack frame for this function so if 
> _NMT_NOINLINE_ is defined you get the caller's caller's FP rather than 
> the caller's FP. I just deleted the function as it's not used anywhere else.
> 
> BTW we can't use __builtin_frame_address(1) as GCC gives a warning when 
> this is called with a non-zero argument (-Wframe-address).
> 
> Tested jtreg hotspot_all_no_apps and jdk_core (gcc 7.3).

OK, that's all good. Thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [13] RFR: JDK-8225392: Comparison builds are failing due to cacerts file

[Erik Joelsson]

I'm happy with this.

/Erik

On 2019-06-14 08:33, Weijun Wang wrote:

Here is the updated webrev

   http://cr.openjdk.java.net/~weijun/8225392/webrev.01/

The only change is ordering in 'keytool -list' and its test.

Thanks,
Max


On Jun 14, 2019, at 7:55 PM, Sean Mullan  wrote:

On 6/14/19 1:49 AM, Weijun Wang wrote:

BTW, something not related but similar: Do you like me to also sort aliases 
alphabetically in the output of "keytool -list"?

Yes, I think that is useful.

--Sean

[13] RFR: JDK-8225392: Comparison builds are failing due to cacerts file

[Weijun Wang]

Here is the updated webrev

  http://cr.openjdk.java.net/~weijun/8225392/webrev.01/

The only change is ordering in 'keytool -list' and its test.

Thanks,
Max

> On Jun 14, 2019, at 7:55 PM, Sean Mullan  wrote:
> 
> On 6/14/19 1:49 AM, Weijun Wang wrote:
>> BTW, something not related but similar: Do you like me to also sort aliases 
>> alphabetically in the output of "keytool -list"?
> 
> Yes, I think that is useful.
> 
> --Sean

Re: RFR: JDK-8225392: Comparison builds are failing due to cacerts file

[Sean Mullan]

On 6/14/19 1:49 AM, Weijun Wang wrote:

BTW, something not related but similar: Do you like me to also sort aliases 
alphabetically in the output of "keytool -list"?


Yes, I think that is useful.

--Sean